using gettext for .desktop translations

[Chusslove Illich]

> [: Jonathan Riddell :]
> The original proposal is in the attachment at
> http://lists.freedesktop.org/archives/xdg/2005-June/005344.html
> [...]
> https://bugzilla.gnome.org/show_bug.cgi?id=569829

Given these discussions, as well as Oswald's note about Maemo in the earlier
message, I will take it for granted that performance is not a problem.

I tend to agree with Mark McLoughlin that dynamic translation should not
really be called optional, but that instead the current static system should
be deprecated. Such that all readers of .desktop files are expected in time
to be able to fetch translations dynamically. So a compliant reader would
have to use Gettext (or roll own equivalent). For me personally, this is
acceptable. For transitional period, upstream .desktop files would continue
to ship/install with static translations, but spec should state that dynamic
translation has higher priority.

Same as I have, Matthias Clasen has strongly remarked that the .desktop spec
should be formally updated before anything is done in upstream
implementations. The .desktop spec lists 5 authors in the opening (among
them Vincent Untz, who had also participated in the above thread on Gnome's
Bugzilla) -- is it really that none of them is available (or willing, e.g.
due to coupling with Gettext) to introduce dynamic translations into the
spec?

Thinking further, I don't think having only the domain name in .desktop file
is sufficient. Domain name is one of the two pieces of information used to
determine the correct location of the MO file. The other piece is provided
by bindtextdomain(3) call, which states the base directory where
<lang>/LC_MESSAGES/<domain>.mo are looked up. If install two versions of the
app from source on different locations on the system, each must fetch
translations from its own <prefix>/share/locale, and so must the reader of
their .desktop files.

So, since dynamic translation would be defined in Gettext terms (unique
catalog name, semantic of contexts), and given the lookup information
needed, I'd propose the folowing field and value format:

  GettextBinding=<basedir>:<domainname>

The problem is that this means that .desktop files must be modified at
install time, to insert the configured base directory. To me this looks on
the verge of being a showstopper, but I'm not much into build systems.
Hope someone has a better idea here :)

>> [: Chusslove Illich :]
>> [...] How about having a *-Context counterpart to every translatable
>> field (as they are currently listed in the spec)?
>
> [: Jonathan Riddell :]
> [...] Could the name of the .desktop file be used as a context?

No. While file name together with field name would technically disambiguate
the string, it is not how contexts are meant to be used in Gettext sense.
E.g. a message in PO file should not change (= neither msgid nor msgctxt
should be modified) just because the source file was renamed.

As for field-wise approach, I'd rewise it to *GettextContext counterparts
for translatable fields: NameGettextContext, CommentGettextContext, etc.

> Pure Qt apps already have to use a second translation system merely for
> the sake of .desktop files. [...]

Well, I suppose they follow the current .desktop spec, so they are using a
second translation system for .desktop files in the same way as everything
else currently does.

Frankly, I don't care dropping Gettext on everyone: Gettext is as "foreign"
to KDE core library as it is to anything else, so if KDE can make use of it,
I don't see why others cannot. MO format is quite easy too, so those
unwilling to go through glibc or libintl, can really (not hypothetically)
roll their own support -- this is done in Python standard library.

-- 
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/d0f551ae/attachment.sig>