====== Multilingualism ======
With version 2.2 Admidio supports multiple languages. For this purpose, all the texts were stored in an XML file in **adm_program/languages** with the respective language abbreviations as the filename. The language can be selected in the **Organization Settings** within the **Regional settings** area.
==== Using in source code ====
In the **common.php** a global object **gL10n** of the Class **Language** is applied, which is derived of the PHP class [[https://secure.php.net/manual/en/class.simplexmlelement.php|SimpleXMLElement]]. This object reads the XML file. About the method **get($textId, $params = array())** the search text can be handed over with the ID. It returns then the text in the set language respectively. Does the text have placeholders (#VAR1#, #VAR2# ...), so this can be passed as additional parameters.
Example:
// the following call returns in German "Anlegen" and in English "Create" back
$gL10n->get('SYS_CREATE');
Does a text not exist in a language , the corresponding text of the reference language is taken automatically. The reference language is english (en).
==== XML language file ====
The XML file is structured as follows:
House
Dog
This is a very long text where it's not possible to get a good identifier.
This is a #VAR1# text where it's possible to set some #VAR2_BOLD# placeholders.
There is a resource-node which contains several string-nodes. Each string-node contains an attribute **name**. This attribute must be unique and identifies the respective text. The **name** is fully capitalized and separated with an underline to each word. The string-node itself contains the text in the language of the file.\\
The texts are to be sorted in the XML file alphabetically per module area according to the **name**.\\
Module-specific texts and words are to be assigned to the module fields. In the long term, it is planned to load the module-specific texts only when the corresponding module is called.
==== Rules for the name ====
The **name** should always be written capitalized and isolated with underscore to each word. It starts with a //3-digit abbreviation// of system //SYS//. You should not use the abbreviation of the modules anymore. English, therefore, that it is easier for translators who are not proficient in German, to identify the right texts. After the symbol then the content of the text should be summarized as short as possible, so that you know about what it is, when you see only the **name**. It makes sense to add also verbs to the end to group texts by sections, e.g. **PRO_PHR_PHOTO_SAVED PRO_PHR_PHOTO_DELETED**. Help for correct translation of the German word into English **name** can be found at [[https://translate.google.com |Google Translator]] or [[https://dict.leo.org|Leo]].
Examples:
SYS_ANNOUNCEMENT
represents //Announcement//
SYS_NO_ENTRY
represents //The requested item does not exist in the database.//
SYS_PHOTO_DELETED
represents //The profile photo has been deleted.//
==== Design options in the text ====
In translatable text placeholders can be defined that can be filled in later recall of the text with variable content. Placeholders are defined as **#VAR1#**, **#VAR2#**, etc. Calling the **get** - method they are passed successively within an array in the second parameter. If not all or none are required, then the getter becomes simply passed fewer arguments.
$gL10n->get('SYS_EXAMPLE', array('Text for VAR1', $content_var2, 'VAR3'. $content));
If the contents of a placeholder are issued **bold**, this is possible in the text with the addition **_ BOLD** to the variable name **#VAR1_BOLD#**.
Fixed line breaks within the text can be specified via **\n**. These will be replaced later for displaying on the homepage by **
**.
==== Multilingualism in Plugins ====
Please have a look at [[en:entwickler:how_to_make_your_plugin_translatable|How to make your plugin translatable]].