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.

In the common.php a global object gL10n of the Class Language is applied, which is derived of the PHP class 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).

The XML file is structured as follows:

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <string name="SYS_HOUSE">House</string>
    <string name="SYS_DOG">Dog</string>
    <string name="SYS_LONG_TEXT">This is a very long text where it's not possible to get a good identifier.</string>
    <string name="SYS_PLACEHOLDER_TEXT">This is a #VAR1# text where it's possible to set some #VAR2_BOLD# placeholders.</string>
</resources>

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.

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 Google Translator or 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.

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 <br />.

Please have a look at How to make your plugin translatable.