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

* Your Email Address
* Spam protection	Enter the letters below: . . ..__ .___. . \| \|\/\|[ __[__ \|_/ \|___\| \|[_./[___\| \
Comment	> 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?
Attachment
Watch this ticket

Saved Queries