[Kde-games-devel] Parsing and translating XML game-data

[Ian Wadham]

> > I can use QDomElement::text().toUtf8().  It gets back a "u"
> > with umlaut in 2 bytes as expected, but I am not sure I get
> > back all my whitespace and I certainly *lose* the format tags.
Josef Spillner wrote:
> You can use:
> QString foo;
> QTextStream bar(&foo);
> bar << your_element;
>
Thanks very much, Josef.  That works well, except it sometimes
inserts a space (default "indentation") between adjacent tags and
untags.  Best, I have found, is:

    your_element.save(bar, 0);

which saves all the text to the text stream, format tags included,
with zero-length for the indentation.

Burkhard, it is "QDomElement::text()" that drops lower-level
tags (as documented), not ".toUtf8()".  They never get into the
QString that QDomElement generates.

> > Or should I abandon XML, use some simple home-grown format
> > and hand-code the parsing?  Or maybe use KSimpleConfig?
> I think using XML for game data is fine, a lot of games switched to
> doing so since the X stands for eXtensible and this has proven to
> be a good thing.
>
BTW, I see "meinproc" does its own parsing (on KDE apps doco) ;-)

The real concern lies in using i18n() for lengthy texts, such as game hints.
If there is just one byte difference between what is extracted from the game
data at run-time and what was stored earlier in a .po file (even a space or
newline), translation will fail unexpectedly.  With its present dual-copy
approach (one in gamedata/ and one in src/data_messages.cpp),
KGoldrunner level-name/hint translation has been broken twice in
the last three years by people changing one copy but not the other.

In the XML world, if QDomDocument _does_ massage the text in some
unexpected way, it will be important to use identical program code to
extract the .po strings and the run-time strings, so that the same massaging
occurs in both places and will cancel out when i18n() is called.

Was there at some time a flavor of i18n() that went
i18n (key, string-to-translate), where "key" is a short key such as
"level007hint" that never changes and is used to look up the translation?
If there were such a thing, strings could change in minor ways that
do not affect the meaning substantially and translations would not
have to stay in lock-step with such changes.

Just an idea, Ian W.