Language and International Enhancements for Version 1.6
In version 1.5, we are limited to language prefixes of 2 letters at installation time. i.e fr-FR and not fra-FR. In all other areas of Joomla!, we can use 3-letter language prefixes. Many languages in the world can't be accomodated with a 2 letters prefix. ISO gives each langage a prefix. For example "ast" for Asturian (Spain), "sla" for Montenegrian (Montenegro) etc. See http://www.loc.gov/standards/iso639-2/php/code_list.php
Joomla tries to propose a specific language for installing depending on the browser's settings. Let's say a browser is set to use Slovenian as preferred language (sl). If, among the installation languages proposed by Joomla, we have a 3 letters ISO code language which tag starts by "sl" - the prefix- (for example for Montenegrin sla-ME) and IF the sl-SI Slovenian language pack is not present among J! languages, then a Slovenian would be presented with a Montenegrian first install screen.
No browsers as of today include 3-letters ISO languages. The only solution to prevent this is to default all 3 letters code Joomla! languages to English in the first install screen. At that point, you can choose the correct language for installation.
The issue is not present when a user installs a customised distribution of Joomla as the installation language can be defined in the localise.xml file.
Transliteration is used in Joomla! to automatically create or modify non-compliant aliases into ASCII strings. These aliases are used for creating SEF URLs. I.e the title of an article or menu item can be "Émergé", the auto alias will transliterate it into "emerge"
In 1.5, this transliteration would not know how to manage for Latin supplement, Extended A letters used in some central European countries and people had to modify manually their aliases when created automatically.
In 1.6 has been added a table to help take care of most Latin languages.
Note: As in 1.5, when non latin glyphs are entered in the Title field, alias field is left empty and Unicode slugs are not implemented (see below), the alias field will automatically be filled with the present date)
For people who still want to use ASCII SEF but are not using a Latin language(Cyrillic, Greek,...) or with specific usage (some weird math glyphs, etc.) we have added the ability to override the default Latin transliteration by adding some code in a specific file called xx-XX.localise.php (use correct lang tag) in the core language pack for their language.
We have such a file and a sample table for Latin 1, Latin supplement , extended A, Cyrillic, Greek in the temporary xx-XX site language folder in 1.6 trunk (this language will be taken off when 1.6 reaches RC). It adds a table where all the said glyphs are transliterated to their ASCII counterparts, charge to the Translation Team providing the packs to make sure this transliteration is correct.
For example ω will be transliterated into an "o", etc.
Concerning the xx-XX.override.php see: http://docs.joomla.org/Tutorial:Making_a_Language_Pack_for_Version_1.6
All usage of this file is explained there in details.
Opposed to transliteration, one may now use natively in 1.6 Unicode urls. This parameter is defined in Global Configuration. This way of making aliases does not transliterate, it displays the utf8 glyphs instead of ascii. It uses Percent Encodings to display correctly ( http://en.wikipedia.org/wiki/Percent-encoding ).
Wikipedia demonstrates this in Persian: http://ps.wikipedia.org/wiki/فارسي is in fact: http://ps.wikipedia.org/wiki/%D9%81%D8%A7%D8%B1%D8%B3%D9%8A
Browsers behave differently when copying such urls. Firefox will copy the unicode format while Opera will get the original glyphs. Google has no problem searching or referencing such links.
If you wish to change an existing value for a string present in Joomla! core or for a specific extension, the only solution in version 1.5 is to edit the ini file concerned and change the value of the string.
When updating Core, the extension or a translated ini file, your local changes can be overwritten if there are updates to the edited language file.
The new xx-XX.override.ini file has been created to avoid this issue. Instead of changing the original file, one can add in a file tagged to the language chosen (en-GB.override.ini for example) any key already existing somewhere among all ini files and a specific value.
The file has to be placed in administrator/languages/overrides/ or languages/overrides/ for frontend.
For example, if you add the following value to the override.ini file:
JSAVE="Save now!", then this will replace the
JSAVE="Save" throughout your site.
This file will not be uninstalled or overwritten when updating. Since the override file loads last, ALL keys present in your Joomla can be overriden.
In version 1.6, language files can be added to a language folder under the extension folder. For example,
Extension developers can choose this solution instead of adding the language files inside the core folders. This does not prevent adding translation of these files in the main core folder. Users have still to beware when uninstalling a language, since this will delete all ini files in the core language folders, included extension-related ones.
The .sys.ini language files are used for extension description translations on the install and update screens. These files are used so that descriptions of all extensions in the system can be loaded at once. This avoids the overhead of loading and parsing full language files for every installed extension. If you only need the description or name of an extension, it is preferable to load the .sys.ini file instead of the .ini file.
The new sys.ini file replaces the .menu.ini in 1.5 and provides translation in some Managers.
As the 3pd can now include specific script at install time, the sys.ini is also used in case these scripts contain language keys.
This is a simple multilingual solution provided by one module and one plugin. See the tutorial Language_Switcher_Tutorial_for_Joomla_1.6.
1.6 uses a new function JText::plural() for usual ones.
will use the following ini strings:
COM_USERS_N_USERS_ACTIVATED="%s Users successfully activated" COM_USERS_N_USERS_ACTIVATED_1="User successfully activated"
To which could be added for languages where the equivalent to the word "Users" is different for 0 and for multiple:
COM_USERS_N_USERS_ACTIVATED_0="0 (or No) users activated"
Concerning extremely customised languages where the value not only changes for zero, 1 and >1 but also for 5 for example (Russian) and depending of context, this is done in the same file xx-XX.localise.php stated above for transliteration.
This needs to be done this way because MySQL accepts only Gregorian dates, thus the need to calculate when saving and when loading for these languages.
This new meta parameter is set in the language xml file in each language pack.
means that Sunday is considered as the first day in the week.
For French or Italian it would be Monday
The xx-XX.override.php is also used to define new parameters concerning search.
It replaces the xx-XX.ignore.php in 1.5 and includes new functionalities:
In 1.5 any front-end display created by some plugins could not load their lang file in front-end.
This forced some 3pd to code specially to get these strings loaded. In version 1.6, plugin language files that exist in the back-end are loaded when the plugin renders output in the front end, eliminating the need for special code by 3pds.
Front-end templates using custom strings in the front-end need to have a separate language file for front-end in 1.5.
In 1.6 we need only one file which is loaded in both the front and back ends. This ini file will now load custom template override strings as well.