> >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. > > Can gettext handle this files?
Yes. Look at /usr/share/locale/de/LC_MESSAGES on your system, for instance....and compare with /usr/share/locale/de_DE/LC_MESSAGES. Some software build systems build fr.mo and put it in /usr/share/locale/fr even when the originating file is fr_FR.po The consequence here is minor...but this is broken as well..:-)...because here the few cases where a difference is relevant (pt, zh) will be ignored. > >You can also mention that the bug probably 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 expcetions to this are: > > Is this this a Debian rule? (If yes, can you please mention the chapter...I > could not find anything in Policy Manual and Reference). Because horde's > translation README says: > --- > You now have to create a new PO file for your locale. A locale has the form > ``ll_CC`` where ``ll`` is the two letter `ISO 639`_ code of the language and > ``CC`` the two letter `ISO 3166`_ code of the country, e.g. ``de_DE``, > ``en_US`` or ``pt_BR``. They *are* wrong. 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. 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. Again, the known and widely accepted exceptions to this are pt_BR, zh_CN and zh_TW translations (and probably soon pa_IN/pa_PK because of scripts differences). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
