3-Letter Language Prefixes for Installation

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" fro 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.

Default Latin Transliteration

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.

Custom Transliteration Support

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. It adds a table where all the said glyphs are transliterated to their ASCII counterparts, charge to the TT to make sure this transliteration is correct.

Unicode URLs

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 ).

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.

Language String Overrides

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.

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.

Language Folder For Extensions

In version 1.6, language files can be added to a language folder under the extension folder. For example, mod_mymodule/language/en-gb/en-gb.mod_mymodule.ini.

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 language folder, included extension-related ones.

The new .sys.ini

Extension description translation at install/update. Include specific scripts if desired.

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.

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"

etc.

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.

Support for Non-Gregorian Calendars

In the display of the date in front and back-end calendar fields, we need to be able to override the Javascript files used to render the dates. In version 1.6, we can now do that by installing custom Javascript in the media folder. That means that in version 1.6 Persian or other distributions no longer need to be hacked to get local calendar display and that these sites can be truly multi-language and permit switching and get the right calendar for the language concerned. 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.

Plugins Language Files

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.

Templates Need Only One Language File

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.