[RkWard-devel] plug-ins & translation

[Thomas Friedrichsmeier]

On Tuesday 16 January 2007 13:41, Stefan Rödiger wrote:
> Recently we can see several new plug-ins emerging. The downside is that
> there is still no easy we for people who don't want to dig in the code for
> translating purposes. I think it's a good moment to think over this again.
>
> I'm not aware of a GUI tool to do this. How are other projects handling
> this or is there a project with a similar structure that could provide a
> suggestion (or even solution)?

While I don't really have a solution, yet, I think we should definitely rely 
on gettext and consorts. This will mean generating .pot files, translating 
to .po, and compiling to .gmo as is currently done for the C++ strings.

Altough this is not complete, I'm writing down, what I know so far, here, so 
it's documented somewhere, and maybe someone has some additional insight.

This involves the following tasks (among others):
1) Write an extraction script that finds all translatable strings in XML and 
PHP files, and writes them to a temporary file that xgetext understands. KDE 
has the tool "extractrc" for extracting strings from the ui.rc files. While 
we will not be able to reuse this directly, this should give a good example 
on how to write such a tool. An important point will be to make sure that 
equal strings from different plugins can be translated separately.
1b) The XML-files will not need to be prepared for this in any special way. In 
the PHP-files, translatable strings will have to be marked up with i18n (), 
similar to the way it is done in the C++ sources.
1c) This i18n () macro for PHP will have to be written, of course, and 
possibly additional code to allow the PHP files to look up translations 
directly, without doing lots of internal calls to the C++ code. But that's 
technical details to worry about later.

2) The code in the "plugin"-subdirectory (not "plugins") will have to be 
adjusted to
a) Determine and open the needed message catalog (see bindtextdomain ()). One 
difficulty is that we have to support externally contributed plugins (that 
will ship their own message catalogs), but we don't want to have one catalog 
per plugin, either.
b) Look up the translations using dgettext () (we cannot use textdomain (), 
and gettext (), as we will be dealing with multiple catalogs). Since most 
translatable strings are parsed from XML-attributes, 
XMLHelper::getStringAttribute () should gain an accompanying 
getStringAttributeTranslatable () for this purpose, and that should be used 
in many but not all places (not all strings are translatable).

3) Create makefile magic that will run the extraction tool on all relevant 
files, compile .gmo catalogs from translated .po files, merge changed/added 
strings back into .po files reliably, and install the .gmo files to a 
sensible location.

4) Document how to do translations, and what to keep in mind to make plugins 
easy to translate.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070116/9aa8e330/attachment.sig>