Since this had to be done before Horde 4 is released, I've done it now.

Thanks for this analysis.

I agree that this is not critical neither important bug. I have just 
filled it to ensure that all bugs reported to debian (and not debian 
specific) are known here. Also, as the debian bugs point to this one, 
someone really needing it fixed can provide a patch ;)

I have played around with this a bit more.

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

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?

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>

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.
I didn't know that. This bug is then less relevant, it is just to 
remove the need to maintain $nls['aliases'].

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>

Regards

Mathieu

Discouraged by whom?
The Horde NLS class is taking care of this already.
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.

Using a country part in a translation file is a discouraged practice
except in very few cases (such as pt_BR).

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 language does not vary among countries and, again, this is not the
general practice for programs localization.

The bug also occurs for other translations. In general PO files should
only be named after the ISO_639 code of the given language and
should not use a country part with a ISO-3166 code. The only
accepted exceptions to this are:

-pt_BR for Brazilian Portuguese and pt alone for "standard Portuguese"
-zh_CN for "Simplified Chinese" use in mailand China and Singapore
-zh_TW for "Traditional Chinese" used in Taiwan

Lat both are different ways of wrinting Chinese, not to be confused
with Mandarin/Cantonese which are different ways of *speaking*
Chinese....both being written the same way.

regards

Mathieu P

(Wordings taken from http://bugs.debian.org/336798)

References:
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336812
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336815
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336818
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336824
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336798
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336800
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336819
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336820
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=336821