using gettext for .desktop translations

[Chusslove Illich]

>> [: Chusslove Illich :]
>> [...] What you say is that two versions of application cannot coexist and
>> be properly translated. This would be fine if two versions of application
>> could not coexist at all, but this is normally not the case and would be
>> considered a bug if so.
>
> [: Oswald Buddenhagen :]
> huh? you're effectively questioning the entire xdg dirs concept. it isn't
> much of a difference whether the conflics come from only icons and desktop
> files or also other data files (i.e., translations). the solution has
> always been installing into a separate directory and adding the paths to
> the environment [...]

I certainly agree that if the resource covered by a Gettext domain is itself
looked up by preference of paths in environment variables, then there is no
conceptual disadvantage (but there is practical, see below) to the MO file
too being looked up in the same way.

I'm just pointing that (1) there is diverse usage of .desktop files (and
files being .desktop just by format) and not all follow XDG specs (nor are
even intended to) and (2) this is not how Gettext normally works, and if
something gets screwed up, user sees partially translated interface.

In particular for (2), the reader of .desktop files would have to find MO
files itself, it couldn't use bindtextdomain() directly and just fire away
gettext() calls. It would have to reproduce Gettext catalog resolution
behavior[1] and combine it with XDG paths. KDE core does this internally (it
cannot rely on bindtextdomain() for other reasons), where equivalent of XDG
paths is KDE config, and it's not pretty. The updated .desktop spec would
have to detail this, instead of just pointing to bindtextdomain(). Also the
question of what this means for performance, as none of the patches I've
seen so far does any of this.

[1] Consider LC_ALL, LANG, LC_MESSAGES, parse locale and try subcombinations
by priority, fallback by language according to LANGUAGE, killswitch on
LC_ALL set to C or POSIX. I possibly forgot something.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091212/43fe6cbf/attachment.sig>