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

List:       koffice-devel
Subject:    Re: I18n in koffice scripts
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2008-12-13 13:04:14
Message-ID: 200812131404.15199.caslav.ilic () gmx ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> [: Dag Andersen :]
> I implemented internationalization of my 3 python scripts using the
> existing tr() functions in kross. I then did a simple grep + sustitute to
> create a py.cpp file (attached). Would this be usable for message
> extraction/translation at all or do we need something more complex?

But why this? "Proxy" file for message extraction should be used only when
xgettext cannot extract message directly from a given format, and from
Python code it can. In particular, proxy files should *not* be used when the
format is program code, unless absolutely necessary (when xgettext just
doesn't know the language yet), in order to be able to control what is it
exactly that's being wrapped for translation. If you want to avoid to have
to type e.g.:

  self.dialog = self.forms.createDialog(an_i18n_call("Busy Information Export"))

for the above reason this really shouldn't be avoided. But call name can be
shortened, e.g. pure Gettext projects frequently use shorthand, single-
underscore call like _("Yadda, yadda."), with _() being a thin wrapper
around gettext() (a macro even where available).

Also, since these are Python sources, xgettext must be given parameter
--language=Python, to be able to parse code and properly recognize native
Python format strings that these scripts use (which are unlike KDE or Qt
format strings). If special call names are used, xgettext should be told
about them using -k option (and I suggest not using i18n* call names if
under the hood they have nothing to do with KDE's i18n, to stave off any
confusion later). These two points mean, as I've said before, extraction to
a separate PO file for these scripts.

Now, how the messages from that PO file are used at runtime, is the matter
of implementation that we've discussed. If under the hood Qt's tr() is used,
then somehow PO should be converted into Qt Linguist format, and in general
Qt i18n infrastructure established (of which I know nothing about...)
Another option is not to use tr() provided by Kross, but native Gettext
calls, when PO files will be directly usable (assuming proper installation
and initialization, of course, which is described in Python standard library
docs).

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

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

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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