Support for i18n in data files

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.ilicgmx.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.

_______________________________________________
kde-games-devel mailing list
kde-games-develkde.org
https://mail.kde.org/mailman/listinfo/kde-games-devel