Hello
Sergey Poznyakoff wrote:
Can you explain a bit more the work in frontend/php/include/i18n.php?
The changes aimed to make Savane determine automatically whether a requested
translation is available and to provide for a flexible algorithm of
selecting a matching translation.
Currently, when adding a new localization to Savane, one has to modify
i18n.php by adding a set of `language=>localization' correspondencies to
$supportedLanguages array.
Yes it is a little annoying, but in regard to the translation contribution we
have it should not be such a pain.
Usually several entries are added to the
array, for each territory where the language is spoken, plus a general,
territory-independent entry. E.g., for German:
...
"de" => "DE.UTF-8",
"de_DE" => "DE.UTF-8",
...
This scheme is rather weak. First, it does not fully describe the
localization: in the above example, at least de_AT and de_CH are
missing, so a person which has any of them set in his browser
preferences will never get the German translation.
No, it fail back to the default qualified "de" : de_DE.UTF-8
Secondly, given
sufficient number of available localizations, this array will grow very
large and difficult to maintain.
The proposed solution uses a single array which defines a `default'
country code (ISO 3166) for each language code from ISO 639 (the notion
of the `default code' is described in the comment before the array
definition). This array has about 180 entries and will hardly change in
the foreseeable future, so there is little maintenance burden. When
analyzing browser preferences, if a qualified locale code is found, it
is processed as usual, i.e. Savane tries to find an exact matching
localization. If an unqualified language code is found (e.g. 'de', or
'fr' ...), its default territory is looked up and appended to it to get
the fully qualified locale name, useful for verifying whether the
localization is actually available.
The actual code was design to do that, no ?
I future I plan to add further improvements that should allow to pick
the closest translation when no strict match is found. For example, if
the requestor browser specifies a preference for 'fr_BE', and we do not
currently have this localization, it is always reasonable to return
`fr_FR' (available for Savane), instead of the default `en_US'.
If a qualified language is not found, it looks for the "unqualified" language
and get the default one : fr_FR.
line 63 : $curlocale = 'fr' if user ask for 'fr', 'fr-fr' or 'fr-be'
line 66 : looks for specified qualified language
line 73 : fail back to the default (not qualified) language
Notice also, that there is now no need to modify i18n.php when adding a new
localization. It suffices to copy the $lang.po file to savane/po.
If the performance impact is correct, autodection (looking for .mo files)
should be a good idea.
Regards,
--
Stéphane Urbanovski
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
