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

List:       kde-i18n-doc
Subject:    Re: KDevelop and KDevPlatform
From:       Pino Toscano <toscano.pino () tiscali ! it>
Date:       2008-11-23 23:32:48
Message-ID: 200811240032.52737.toscano.pino () tiscali ! it
[Download RAW message or body]


Hi,

> Pino approached me today asking what the plan is with those two modules as
> it seemed that so far nobody took care of i18n related things
> (message-extraction, how many catalog files and so on). And thats correct,
> the kdevelop module in trunk/KDE simply had the same stuff applied that has
> been applied in any other module and IIRC we just copied its Messages.sh
> script into kdevplatform/

And furthermore: the kdevplatform is not handled at all by scripty.

> Unfortunately I think in our team we don't have anybody thats familiar with
> out i18n stuff is done. So we'll need some pointers to help us out. We'll
> certainly willing to do the "dirty" work (i.e. coding-stuff) to help the
> translators.

And we can help you with the various Messages.sh :)

> So, whats needed from our site to make the message-extraction work as it
> should? As I understand the Messages.sh I should put a second Messages.sh
> into kdevplatform/plugins to separate the plugins messages from the ones in
> the libraries. So that in distributions there are two -i18n packages
> possible.

Well, the number of Messages.sh files does not matter at all; in the end, you 
will end up shipping all the translations of each a language of all the .pot 
templates you provide.

> I don't think having a separate pot for each plugin makes sense and neither
> does it for the libs. The kdelibs module also has only one big pot. Is
> there anything else?

Not entirely true, kdelibs has few as well, as you can see[1]; although, the 
bigger distinction is kdelibs4.po and kio4.po.

I personally would suggest to create one .pot for each kdevelop plugin, and 
one for the main application (the kdevelop shell).

This has some advantages:
- there's no "huge giant template" like in kdevelop3 (so easier to maintain)
- easier to handle in the code: when loading a plugin, you load also its 
catalog (whose name is specified in the KAboutData of the KComponentData 
loaded via the KPluginFactory); this allows single plugins (eg 3rd party 
ones) to be shipped alone with their translations, with no need to rely on 
them being in the man kdevelop.pot/kdevplatform.pot
- it is easier to "share" among translators (eg translator A works on foo.pot 
and translator B on bar.pot, without stepping on each other toes and waiting 
for each other)

The disadvanges include:
- some strings could be duplicated in more .pot (although this is not a common 
situation); this can be solved partially on translators' side by using 
translations memory of your favourite translation application
- when packing a release, you need to pack more translation files (although, 
if you get shipped with KDE, then this is done for free)

[1] http://websvn.kde.org/trunk/l10n-kde4/templates/messages/kdelibs/
-- 
Pino Toscano

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

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