locale specific for .desktop

[Takao Fujiwara - Tokyo S/W Center]

Brian J. Tarricone wrote:
> Takao Fujiwara - Tokyo S/W Center wrote:
> 
> 
>>How about a new "%l" since Exec line supports some field codes?
> 
> 
> Why?  If the application launching the app in the Exec line knows what 
> $LANG is, then the application that gets launched knows too, and can 
> figure out what to do based on $LANG; there's no need to pass the locale 
> on the commandline.
> 
> You shouldn't be opening hardcoded paths in .desktop files anyway; if 
> you need to open different files depending on $LANG, you should write a 
> small helper application to figure things out for you.  If it's a 
> help-system type thing (for example), use an existing mechanism outside 
> of the desktop entry spec to do this.

So It's appropriate each application needs to handle $LANG and $LANGUAGE.
OK, I see.

> 
> 
>>How about adding a new key OnlyShowInLang ?
> 
> 
> I guess I still don't understand why this is necessary.  If a user 
> installs a piece of software that installs a .desktop file, my feeling 
> here is that they want to be able to see it regardless of what 
> LANG/LC_ALL is set to.  If it doesn't apply to their language at all, 
> then why would they have installed the app in the first place?  If it's 
> a distro-installed app that the user doesn't want, it should show in the 
> menu so the user is aware of it and can uninstall it if he/she so desires.

Some of the applications are used on one locale only, e.g. Chinese dictionary application, Japan road map application.
The situlation is, those applications are used for one country only, the native persons require to show the application by default, the native person usually uses one locale only.
But we don't have suitable applications for all locales so the .desktop needs to be shown on one locale only.

> 
> IMHO installing multiple .desktop files for an app (e.g. 1 per language 
> for some number of languages) is foolish, and just slows down menu 
> implementations.  The app itself should deal with the locale 
> appropriately by examining environment variables.
> 
> Personally, I'd prefer we didn't add complexity to the spec when the 
> same functionality can be handled outside it.

The problem is we don't have any way to handle this case.