Parsing and translating XML game-data

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

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