[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: I18n in koffice scripts
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2008-12-05 23:03:20
Message-ID: 200812060003.21580.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Sebastian Sauer :]
> Thanks for the details. Well, if I got it right, then I don't see the
> problem with the #if(KDE) i18n() #else tr() #endif cause kde-applications
> will use the i18n() always anyway while the tr() is only for Qt-only apps
> outside of kde (so, no translations from our side needed anyway - means,
> we just don't need to care and the tr() is only there to don't link
> against kdelibs while providing a way for Qt-only apps to still use
> translations).

You got it right, but, in my opinion, this is a very poor state of things.

If code is pure-Qt, then it should use native Qt translation facilities. If
the code was made pure-Qt in the first place, that was in order for it to be
usable outside of KDE context, and these days usable normally means
translated to various languages too. And this should be achieved without
duplication of effort, on either programmer or translator side. A pure Qt
client should be able to "just use" that code, and automatically have
translations made by KDE translators. Conversely, hooking into KDE
translation system if the code is used in a KDE app, is profoundly wrong;
the i18n workings of a piece of code should not depend on its client.

I guess that we historically went this route because it was easy: very
little tweaking to message extraction to extract from Qt code too, no need
to define, request and write any special guidelines for i18n infrastructure
for pure-Qt code in KDE repository. But this should be fixed in the future.
(For translators, we would also have to establish Qt Linguist -> POT -> PO
-> Qt Linguist chain.)

And until this happens, we shouldn't aggravate the situation by leaking KDE-
isms into translation of pure-Qt code. At present, at least any outside
client can take current translation files and make use of them through own,
custom effort. And while some KDE-isms are technically leakable to pure-Qt
code translations (but deliberately prevented), other are not even that
(Transcript).

Erm... to the point :) Please no #if(KDE) i18n() #else tr() #endif. Either
use i18n() for code strictly dependent on kdelibs, or tr() if that is not
the case. And within mixed KDE-pure-Qt body of code, always extract pure-Qt
parts into separate message catalog, i.e. everything which is using tr()
directly or under the hood.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]