bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

xgettext: extracting "foreign format" messages


From: Chusslove Illich
Subject: xgettext: extracting "foreign format" messages
Date: Fri, 3 Apr 2009 21:01:16 +0200
User-agent: KMail/1.9.9

There's a bit of a curious situation starting to take place in KDE
repository. Already several independent pieces of code are written in
Python, using Python-KDE bindings (PyKDE4), and along with it, KDE's i18n
instead of Python native (i.e. thinly wrapped pure Gettext). So, instead of
a message like this in general Python code:

  msg = _("We have %(one)s and %(two)s") % dict(one=something, two=another)

we are getting in Python with KDE bindings:

  from PyKDE4.kdecore import i18n

  msg = i18n("We have %1 and %2", something, another)

The problem then is that xgettext cannot know to equip these strings with
kde-format flag; they are left format-less, and unable to reap benefits of
msgfmt --check.

Generalizing, a program in language X may use bindings of what was
originally written in language Y, and along with it Y-format instead of X-
format i18n strings.

The question is, what to do here? Would it be good and conceptually possible
to generalize signaling to xgettext in which format to expect strings (such
as is now for --language=C++ with --kde or --qt options). E.g. to have
xgettext --language=Python --kde, or tentative
xgettext --language=Python --format=kde do the trick?

One might ask "what's the point of such indirection", but here are two
benefits that I see:

Supposing a somewhat related body of software (such as KDE) is written in
using several programming languages (such as KDE/C++, Python, and there are
Ruby and JavaScript KDE bindings too), translators still get only one format
of strings in POs. This is good for "not confusing" translators, but more
importantly...

Having that single format throughout (and i18n subsystem to handle it), it
can be highly tuned for translation purposes, with bells and whistles that
the translator can rely on irrespective of the programming language in which
the application is written.

(The situation with KDE and kde-format above seems to me as basically a
forerunner of what could grow into an omnipotent gettext-format.)

-- 
Chusslove Illich (Часлав Илић)

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]