Hi!

I'm writing an application that is currently a pure QT4 app. It is designed to run cleanly on both Linux and Windows.

However I plan to integrate it a bit into KDE in future.

Here come the problems with localization/translations.

QT4 uses its own tr()/tr().arg().arg() mechanism and .ts/.qm files.
KDE4 uses gettext and i18n/p and .po files.

How, easily, can I use KDE4's mechanism in my QT4 application without having to closely integrate it with KDE now (apparently making it non-runnable on Windows)?

Thanks!

If the app is not a KDE app, then I would stick with the Qt mechanism (tr(), lupdate, etc). Replacing tr() with i18n() in the future is trivial. The largest amount of work is converting Qt .ts translations to gettext format, but that's something that's largely scriptable.

Standard disclaimers: IMHO, IANAL, YMMV, YADA YADA...

I will go this way exactly

Especially that I have learned today that QT 4.5 preview already supports both .po and .xliff
Linguist has been thoroughly extended to support those 2 formats.

At some point you could consider shipping a KDE framework based on both platforms, i.e. always using KDE's superior localization framework.

Cheers,
_

A bit on topic: why KDE does not use Qt's translation mechanism?

Because at the time the port to Qt4 which became KDE 4 was started, Qt did not support the method of Translation that KDE preferred. Apparently Qt4.5 is adding this, but due to the binary compatibility requirements of the KDE libraries, the current method will remain available until KDE 5.

It is probably not only that.

KDE has a very sophisticated localization implementation, e.g. additional context, special markup for certain types of placeholders or variables.

Cheers,
_

bcooksley wrote:Because at the time the port to Qt4 which became KDE 4 was started, Qt did not support the method of Translation that KDE preferred. Apparently Qt4.5 is adding this, but due to the binary compatibility requirements of the KDE libraries, the current method will remain available until KDE 5.

I know that, and it has not been released yet. My question is: why is gettext prefered?

anda_skoa wrote:It is probably not only that.

KDE has a very sophisticated localization implementation, e.g. additional context, special markup for certain types of placeholders or variables.

Qt's is good as well (IMO better). What I dislike of gettext is that it is written for english speakers. An application has to be written in English or a very similar language.

YeahReally wrote:Qt's is good as well (IMO better).

Ah, interesting. My understanding was that only KDE's system had semantic markup, etc. Other l10n system often just work with HTML like markup without taking into considerations that not all glyph system can apply them equally, e.g. "" is stupid for Asian languages, "" can be realized by using a different glyph.
See also http://techbase.kde.org/Development/Tut ... _Semantics

But nice to hear that Qt now has this as well.

YeahReally wrote:What I dislike of gettext is that it is written for english speakers. An application has to be written in English or a very similar language.

How does it bias for English? As far as I know English is only used because most translators can translate from English into their language.
Especially in community based translation teams.

Cheers,
_

How are translations in KDE4 done? Is it like Qt4 where you use Linquist to do it?

It is very similar to Linguist. You extract every translatable string with xgettext to a PO file. And then you translate to every target language in MO files.

anda_skoa wrote:How does it bias for English? As far as I know English is only used because most translators can translate from English into their language.
Especially in community based translation teams.

The way plurals are handledl.

I know English is a better base language for projects like KDE and GNU. But, for projects outside that or with very different targets, that is so not true.

The world would be a better place if everybody knew Spanish anyway[/jk]

[Edit] It seems to me that Linguist may not had been taken seriously earlier. A pity.

anda_skoa wrote:"" is stupid for Asian languages

True, but "bold" has not semantic meaning, it's a display tag. "strong" should be used instead. But regardless, the problem is solved if you translate the *tag*.

ComaWhite wrote:How are translations in KDE4 done? Is it like Qt4 where you use Linquist to do it?

And the tool for translate .po files in KDE is Lokalize instead linguist

YeahReally wrote:

anda_skoa wrote:How does it bias for English? As far as I know English is only used because most translators can translate from English into their language.
Especially in community based translation teams.

The way plurals are handledl.

You mean that it offers facilities to have as many plural forms as necessary for the target language?

http://techbase.kde.org/Development/Tut ... 8n#Plurals

Cheers,
_

Not the target language, the *coded* language (without translation). As you can see in that page, gettext requires two phrases in english plural style. That is what is English-like. And no, it does not fit most languages.