[Kde-games-devel] Support for i18n in data files

[Ian Wadham]

First of all, thanks Inge, Albert and Chusslove for your many
helpful suggestions.  As you say, Chusslove, there is unlikely
to be a general solution to the problem.

From: "Chusslove Illich" <caslav.ilic at gmx.net>
Sent: Saturday, August 26, 2006 8:06 AM
> > [: Ian Wadham :]
> > Does anybody know if either KDE 4 or Qt 4 have any plans to
> > support translation of strings in data files (i18n or tr)?

> Well, texts must somehow be translated into PO files. This can be two way,
> either by having extraction system support some formats other than
> sources, or as it is now, having programmers somehow reduce the data to
> known format.
>
The second alternative is very tedious and highly error-prone.
I tested my data strings (game titles and hints) by "translating"
them to "en_GB" (prepending a fixed character sequence
to all the "po" strings), then switching to en_GB language and
seeing whether those character sequences appeared.  It took a
while, as I have about 200 levels in my game.  Any slight
difference between my data-file string and the corresponding
dummy string in "data.cpp" then threw up a translation bug,
usually due to some tiny difference in the white space.  It's
*not* the way to go.

> I agree that having only source files as extraction target is not enough,
> but it would also be hard to design some special format, well matched to
> many different needs out there. People would anyway end up converting
> stuff from this to that.

Maybe, but here's an idea.  If we have some kind of "brackets" around
the strings in our data, as we do in our programs, a utility could extract
the strings and merge them into .po files.  This would work with any
format of ASCII text file (maybe the brackets could be "declared" in
line 1 of the file or by using some new kdelib method).  Of course,
the application program would have to remove the "brackets" before
passing a data-file string to i18n() --- or maybe not (?) or maybe some
variant of i18n() could do it.

Binary data files would pose a different problem, but maybe data
could be organised in such a way that the ancient "strings" utility
of UNIX could extract the strings from among the binary (I've often
wondered how "strings" works ...).  Of course, hardcore database
files or encrypted files or both together would pose problems, but
what the hell?  If we could solve 80-90% of the problems, that
would be an advance in any case.

I'm particularly concerned, long-term, about context-sensitive help
files, as opposed to on-line manuals.  It's time KDE started to catch
up with Windows in that area!

> I would only urge that translations are done at runtime, rather than
> collecting data back from translated PO files and building static
> translations (eg. as is done now for .desktop files), regardles where they
> come from. Static translations have caused confusion in the past, as well
> as more fragile release cycle (eg. documentation problems). In other
> words: ...

Yes, definitely.  Read your (English) data-file at run-time then pass
the strings as variables to i18n() whenever they are used.

> No miracles this time, sorry :)

What?  There have been some before? :-)

> Sorry for late reply, I'm in a bit of a crunch time these days :)

Hope I haven't taken up too much of your time, Chusslove ...
All the best, Ian W.