Re: sr@Latn vs desktop files

[Danilo Segan <dsegan gmx net>]

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