using gettext for .desktop translations

[Chusslove Illich]

> [: Jonathan Riddell :]
> Currently .desktop translations are kept in-file rather than using gettext
> .po/.mo files as every other translation does.

This is not true. Pino already gave you the example of Qt's Linguist as non-
PO based *dynamic* translation system (where translation is resolved at
runtime). .desktop translations are currently belong to *static* type (where
translation is resolved at build/packing time), but they are by no means the
only such example -- think of Docbook documentation.

Why do you touch .desktop files' translation got from upstream at all?
Because Ubuntu translators, when they update/change translations in
upstream-delivered POs, may need to update/change also the translations in
.desktop files, in order to have consistency. However, what will they do for
Docbook documentation? In the end, by working around upstream and not taking
into account static translations (PO or non-PO based), you anyway end up
with inconsistencies. So, the proper solution wrt. static translations (such
as .desktop files) for you (as in Ubuntu) right now is not to touch upstream
internals (such as desktop_* POs in KDE repository), but to extract your own
POTs and POs, and do with them whatever you want. Then you have consistency
and everything is under your control.

Now, in my perfect world, everything would be dynamically translated through
PO files: .desktop files, Docbook documentation, wiki pages, everything.
Since perfection must be approached step by step, why not just do it now for
.desktop files? Because, as both Pino and Kevin provided examples, we'd be
doing something ad-hoc that would confuse random clients of .desktop files,
even when they conform the .desktop file spec at Free Desktop. The proper
way is then to first update .desktop spec, and then we can happily switch to
dynamic PO-based translation for .desktop files. (But this shouldn't make
Launchpad maintainers/translators all too happy, as they still have a ton of
other non-handled static translations in the shadows.) Up until then, I
wouldn't touch a thing in KDE Translation Project's way of handling .desktop
files.

Here's an example how of ad-hoc dynamic translation of .desktop files is
already screwing things up. We have these big desktop_* POs per module, and
therefore sometimes we need disambiguation contexts (msgctxt in PO). We have
an internal way of adding disambiguation context, such that our internal
extractor/injector for .desktop files can do the right thing. But, when
downstream uses internal desktop_* POs, of course the disambiugation context
is not handled, and such translations are lost. (I also mention this because
if someone would make a proposal for dynamic translations to .desktop spec
maintainers, it should include provision for disambiguation contexts for any
translatable field.)

-- 
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/20091211/3bf9d347/attachment.sig>