[Tickets #8816] Re: includes a fr_FR.po translation instead of fr.po

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/8816
------------------------------------------------------------------------------
  Ticket             | 8816
  Updated By         | Jan Schneider <jan at horde.org>
  Summary            | includes a fr_FR.po translation instead of fr.po
  Queue              | Horde Base
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Jan Schneider <jan at horde.org> (2010-08-19 09:54) wrote:

I have played around with this a bit more.

>>> Using a country part in a translation file is a discouraged practice
>>> except in very few cases (such as pt_BR).
>>
>> Discouraged by whom?
>
> Quoting again (from the same bug):
> <quote>
> For the vast majority of languages, using a country
> part is irrelevant. Canadians speaks French the same way than French
> do....or Austrians speak German the same way you do (or so closely
> that having separate translations is irrelevant).
>
> Less than a rule, this is general common practice. This does not
> prevent people to use more specialized translations when they feel
> it's appropriate.
>
> </quote>

Just because it is common practice doesn't mean that our way of doing  
things is wrong. The way we package translations works fine and  
doesn't prohibit anything that would be possible with packaging them  
in the proposed way.
The good news is that gettext seems to automatically do the "correct"  
thing and pick translation from either ll/ or ll_CC/ directories, no  
matter if the current locale is ll or ll_CC, i.e. any combination is  
possible.

> Also, using country part only when relevant avoid the use of aliases  
> like in nls.php and don't attach a language to a country.

Unfortunately not, because the bad news is, that even gettext is  
working fine with any locale format in the directory names, the system  
locale names don't. I can't use de.UTF-8 as a locale, it's not  
accepted. I have to use de_DE.UTF-8. This means we need to use the  
full ll_CC locale in Horde internally and keep the alias map.

>>> Using a fr_FR.po file instead of a fr.po file prevents users of fr_CA,
>>> fr_BE, fr_LU, fr_CH and all other existing and future locales for
>>> French to benefit from the French translation of the program.
>>
>> The Horde NLS class is taking care of this already.
>
> I didn't know that. This bug is then less relevant, it is just to  
> remove the need to maintain $nls['aliases'].

See above, we still need to keep the aliases. Though we probably  
wouldn't need the back-mapping anymore, i.e. the mapping from fr_CA to  
fr_FR, because if we use fr for the locale name, gettext already maps  
automatically from fr_CA to fr.

>>> The language does not vary among countries and, again, this is not the
>>> general practice for programs localization.
>>
>> But it may vary. There's different wordings between Swiss, Austrian,
>> and German German for example, or probably between the Iberian
>> Spanish and South American Spanish, let alone the different spelling
>> between British and American English.
>> Including the country name right from the start we are prepared for
>> adding country-specific alternate translations, and don't have to
>> rename the general-purpose translation when we add one.
>
> Yes, but with the no-country-by-default way of doing, you can put  
> only certain strings in the country specific po.
>
> Quoting again (from the same bug):
> <quote>
> For instance, the software can have a fr.po file which will be used as
> a general French translation....and a few fr_XX files for more
> specialized translations. But the common practice is first having a
> fr.po file (and, more important, a fr.mo file after build) before more
> specialized files.
> </quote>

I don't think this is what he meant, and I'm pretty sure it doesn't  
work how you describe it, though I'd have to test this. AFAIK you  
cannot add a fr_CA locale that only contains the differences to fr and  
have everything working automatically. As I understand it, and I think  
that's what the quote means, the only benefit is, that you can copy  
the original fr.po file to fr_CA.po and then overwrite those strings  
that you need. That would only help with starting a new, diverging  
translation though. As soon as you are trying to keep the translation  
up to date, you no longer can benefit from the original translation.  
Please correct me if I'm wrong or if gettext is working differently  
than I think.

So, to summarize, the "only" benefit from using ll instead of ll_CC  
locales is 1) because others do it, and 2) because we can remove the  
fr_CA -> fr_FR mapping logic. This might still justify the renaming of  
the locales, but it isn't nearly as important as suggested in the  
original bug report, right?