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

Johannes Schickel lordhoto at scummvm.org
Sat Nov 27 20:00:21 CET 2010


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.

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.

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.

// Johannes






More information about the Scummvm-devel mailing list