[crossfire] Multilinguism support

[Mark Wedel]

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