Re: sr@Latn vs desktop files



Hi,
Alexander Larsson wrote:

I just noticed the new sr Latn locale when i was building rpms of
Nautilus 2.2.4. It results in this line in the desktop file:
Name[sr Latn]=LiÄ?ni direktorijum
We've had discussions on choosing the code for the Serbian language in latin script on gnome-i18n list earlier in the April. As a team coordinator for Serbian language, I was instructed that this (sr Latn) or similar (sr latin) is the best choice, instead of using the non-existent language code "sp" for that purpose.

When run through the pedantic parser in desktop-file-utils it says:
Error on file "/usr/share/applications/nautilus.desktop": Error in section Desktop Entry at line 40: Invalid characters in locale name

And reading the desktop file spec this seems invalid:
Keys may be postfixed by [locale], where locale is the LOCALE type of
the entry. locale must be of the form lang[_COUNTRY][.ENCODING], where
either _COUNTRY or .ENCODING may be omitted. If a postfixed key occurs,
the same key must be also present without the postfix.
I'd say that this is just Plain Wrong. I consider it a bug in desktop file specification. Also, I believe Keld mentioned that there's a work on new POSIX locale specifier format which would include the script as additional field, but I'm not sure how's that going. Also, "modifier" is already part of the locale specifier, right?

and:
The matching is done as follows: if the current value of LC_MESSAGES is
lang_country encoding modifier, then, if a key for lang_country is
present, it will be used. Otherwise, if a key for lang is present, it
will be used. If both of these are missing, the required key without a
locale specified is used. The encoding and modifier from the LC_MESSAGES
value are ignored.
Is there a solution anyone can think of? How are we to differentiate between two scripts?

The "solution" of removing latin-script translation completely is unacceptable, since there are many who'd prefer to use it (some would actually only opt for it). As you could probably notice, the difference between "sr" and "sr Latn" is significant, so it's not reasonable to enforce one over the other.

Should we instantly update the desktop utils to resolve this "bug", or if not, maybe revert to the old "broken" state (sp and sr as codes)?


Cheers,
Danilo





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]