Re: sr@Latn vs desktop files

[Martin Norbäck <d95mback dtek chalmers se>]

mån 2003-05-19 klockan 16.10 skrev Danilo Segan:
> 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)?

The specification for LC_* values doesn't mandate that the codes used
must be ISO language and country codes, even though that seems to always
be the case in glibc. So maybe it's better to encode the fact that a
different script is used into the COUNTRY (or territory as it's called
in the specification).

Something like sr_YUlatin and sr_YUcyrillic? I don't know the
implications on other things, like fallbacks to sr_YU and sr.

It seems that the @modifier wasn't meant to separate at this high level.

BTW, is there an automatic translation from one script to the other? If
that's the case, maybe it could be built into the system somehow.

Regards,

	Martin

-- 
Martin Norbäck          d95mback@dtek.chalmers.se              
Kapplandsgatan 40       +46 (0)708 26 33 60                    
S-414 78  GÖTEBORG      http://www.dtek.chalmers.se/~d95mback/
SWEDEN                  OpenPGP ID: 3FA8580B