[Scummvm-devel] [Scummvm-cvs-logs] SF.net SVN: scummvm:[54479] scummvm/trunk

[Max Horn]

Am 27.11.2010 um 20:00 schrieb Johannes Schickel:

> On 11/27/2010 10:49 AM, Max Horn wrote:
>> (Moving this to -devel)
>> 
>> The discussion below deals with what return type OSystem::getSystemLanguage should have, a Common::String or a Common::Language.
>> 
>> IMHO it should be Common::String --  otherwise, adding a new translation may require explicit code changes and a recompile. With a Common::String, it is possible to 3rd parties to add extra localizations without any code change, even for language we never knew about, or may not be willing to add to our list of language codes. E.g. I don't really like to add Klingon to our list of language codes, but if somebody wants to make such a localization, and if they also want to set their system locale to that, then why not support that out of the box
>> 
>> I'd propose that indeed we demand that OSystem::getSystemLanguage returns POSIX style locale strings [*], which in turn are slightly modified IETF language tags [**]. There are well-established and well-documented standards, after all.
> 
> I don't doubt they are well-established, but honestly I did not find any 
> open information source about the POSIX locale definition standard. The 
> IEEE one is not available freely AFAIK.
> 
> I did not find any answer so far for example, where exactly are the 
> language codes defined. It seems ISO-639-1 and ISO-639-3 codes are both 
> used there.

Uh... All  information relevant for our purposes is on Wikipedia and on things linked there.

> 
> Also sometimes still legacy ones are used, like iw_IL for Hebrew 
> (Israel) but nowadays it should be he_IL for Hebrew (Israel). If we use 
> this as base for our return value we would expose such "issues" to the 
> client code. It may be that we might want to just accept such "minor" 
> issues and have the user select the locale himself then.


But we don't really *need* to encode this information anywhere if we use a string -- that's the whole point. If we try to translate all locale strings to a Language enum value, *then* we need to deal with the legacy locales you gave as an examples. 
If we just return the plain verbatim locale, then we don't. It'll be up to the user or system admin to setup a correct locale string.

And we are only talking about the default language value here anyway.

> 
> Anyway if you think we should use POSIX style locales and you contribute 
> the documentation so it's clear, I am happy to change the return value 
> from Common::Language to Common::String.

Well, I am also happy to change it, it's rather trivial, after all :).


Cheers,
Max