[crossfire] Multilinguism support

[Nicolas Weeger]

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

Indeed, the call could be made at that point, it would probably make sense 
too.


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

That's possible, indeed. This would also need to be used for what players say, 
for instance - because you don't want random translation :)



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

Yes,  default translation is English.


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

True, but there's a reason for that, you may want to have a specific string to 
distinguish variants.

Eg in English at two places it's the same text, but not in another language. 
So you do need to use a special string in one case, and have a "real" English 
translation looked up.


Another optimisation I see is to add missing strings (as English) to a 
langage, so you only "fail" a bsearch once. But then you need to qsort() each 
insert, though only for each failure, so maybe not too bad.


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

Yes, makes sense too.


>   If one wanted to carry on, name_pl_<lang> could also be added.

*nods*


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

For NPC dialogs (hopefully a big part of the Python strings), the dialog 
itself (.msg file in maps) should contain the translations.

For other things, we'll see when time comes, I think :)


Regards

Nicolas
-- 
Mon p'tit coin du web - http://nicolas.weeger.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.metalforge.org/pipermail/crossfire/attachments/20111114/5b5dcdbf/attachment.pgp>