On 11/12/11 01:04 PM, Nicolas Weeger wrote:
Hello.
I've rewritten part of the i18n support the server had, to make it easier to
figure what message is used in the source.
When you need to find a string, to display or use in a buffer, please use
i18n(who, "English version of the message, with the %d placeholders");
This will enable to write translations in various languages, through the
"message.<code>" files.
Thanks - this makes reading those files much easier.
Random question - could draw_ext_info_format() just default to using i18n() to
passed in strings, or would that just be too costly since a lot of text may be
automatically generated of which you can not have translations (shop listings,
spell lists, etc).
And thinking about it, that may not work very good if a string has already
been translated and is coming from a different source (player chat, object msg,
quest, etc - see notes below).
OTOH, given those sources would be well known in the code, I then wonder if a
new flag could be added, something like NDI_NOTRANSLATE to just tell the routine
not to translate it.
My only thought here is that if all the strings in the source are eventually
translated (which I think would be the goal), then the use of i18n() just
becomes extra work. I would presume that by default, if a proper translation
can not be found, the message would then fall back to english also.
The one optimization I could see here is require that all message strings are
English (as is the case now), and have i18n() just returned the passed in string
in the language setting is English. It appears (at a cursory glance) that if a
user specifies English as their language, there language will get set to
English, and while the locale file for english is empty, a call to bsearch would
still be made, at which point it would fall back to default.
I plan on thinking about archetype, map, quests and various translations, too
:)
Any idea or suggestions welcome, of course.
For archetypes/maps, I think the way to go would be msg_<lang>, endmsg_<lang>,
eg, msg_fr/endmsg_fr, msg_de/endmsg_de, etc.
A nice effect of having the entire msg blob be localized is that any @match
could also be localized to the correct language - having a question be localized
to French by expecting an English answer would just be odd.
If one wanted to carry on, name_pl_<lang> could also be added.
I'm not sure what to do about python scripts, since presumably the text is in
the python script - while the i18n() would work just fine, since the scripts are
in the map tree, having the localized strings in the server is a bit of a
mismatch - I'm not sure if there would be some way to have the localized strings
in the script itself (based around some standard framework, each script has the
translation table declared in itself).
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
