[maemo-developers] Maemo localization to officially non-supported languages

[From: Eero Tamminen]

Hi,

ext Riku Voipio wrote:
> Mohammed Hassan wrote:
>>> It would be interesting to take our current translations and mine them
>>> for the logical ids that map to the same Engineering English, but at
>>> the same time have different translations in some language.  These are
>>> the cases where we would need to use the "menu|Open" construct in the
>>> code instead of the existing Engineering English string.  Identifying
>>> and handling these cases is where I see a large part of the effort
>>> needed to move away from logical ids, so it would be good to get an
>>> overview.
>>>     
>> Multiple logical IDs with the same Engineering English string are needed
>> because the translation might change according to the context.
>>
> Actually, gettext already has tools to handle same text in different context
> without using logical id:s
> 
> http://www.gnu.org/software/gettext/manual/gettext.html#Contexts

Unfortunately this doesn't solve the problem.
It still needs a code change.


The problem with having just Engineering English is following:

1. There's a release with translations
2. Somebody does a translation for a new language and
    notices that in different contexts different translation
    needs to be used, but currently *such context is not provided*
    - whether the context is given as a part of the string or
      extra parameter to gettext is irrelevant, the required
      context is missing
3. To change this, code needs to be updated
    - If gettext context is used, translations don't need to be updated
    - If context is in the msgid, also other translation need to be
      updated, but with proper tools that can be automated

Only solution for avoiding 3) is having _some_ unique identifier
in all strings and this of course doesn't deal with the problems
of strings coming from libraries but being shown in different
contexts (maybe in some language "OK" needs to differ according
to the text given in the dialog...).

Only thing our "unique identifiers" get right is being uniq
(they are not understood by translators without relevant UI specs
& they miss format parameters and thus give compiler warnings etc).


So, there are two solutions to the problem:
- Have a process that can deal with code and translation updates
   between releases, or
- Add some context ID to _all_ user visible strings in the code
   (and rest of the string should contain the correct format
    parameters, be translator understandable etc)

We can use mixed approach depending on component.


	- Eero