From kde-core-devel  Fri Dec 11 20:23:01 2009
From: Chusslove Illich <caslav.ilic () gmx ! net>
Date: Fri, 11 Dec 2009 20:23:01 +0000
To: kde-core-devel
Subject: Re: using gettext for .desktop translations
Message-Id: <200912112123.07698.caslav.ilic () gmx ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=126056305426083
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2149990.qQy46yVjd4"

--nextPart2149990.qQy46yVjd4
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> [: 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
=2Edesktop 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
=2Edesktop 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.)

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart2149990.qQy46yVjd4
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABECAAYFAksiqiYACgkQMSGXgigGr3Fa1QCfZ9qQeeUk5oFvzgDXCzIMG8JV
CZwAoIiqhO5KEXgW6/5ftAND1gynqjuF
=5vIS
-----END PGP SIGNATURE-----

--nextPart2149990.qQy46yVjd4--