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

Johannes Schickel lordhoto at scummvm.org
Sat Nov 27 21:06:19 CET 2010


On 11/27/2010 08:24 PM, Max Horn wrote:
> 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.

Well yeah it covers "BCP 47" quite good. Then again it only claims about 
POSIX matching those, didn't see any real source for that... Let's just 
assume that's true and it might be fine.

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

Actually if we want to do anything with that string we need to know how 
it is build up. And if we furthermore want to have some more or less 
robust way of using the returned locale in say the translation manager 
(or other client code) we need to worry about such issues.

At least I am not sure how you think the translation manager should pick 
a language based on that value in case it doesn't know about the 
contents, but maybe I misunderstand your "But we don't really *need* to 
encode this information anywhere if we use a string -- that's the whole 
point. ". It just seems to me that it tries to say: "well if we vaguely 
say what's in the return value all is fine, we do not really need to 
worry about what we really get in the end".

It is true that if we return a Common::Language we would of course still 
need to worry about that in the backend code. In the current usage 
example it might be true that only letting the translation manager worry 
about that might be easier, i.e. no additional need to mess around with 
Common::Language entries etc.. In the end if more code wants to take 
advantage out of the locale we still would need to worry about it in all 
client code places.

Actually it just feels better to have it hidden inside the backend than 
exposed to the client side, but then again I am not too focused about 
that. If you think Common::String is fine, fine with me. We can worry 
about that later when we get into issues because of that anyway.

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

If we ignore some "legacy" locales for example we would just miss that 
currently aye. It still feels bad to expose such things to the client code.

Also letting the user/sysadmin worry about setting a "correct" locale 
string is rather hard, for example on some systems (at least Linux) you 
can not set the LANG or LC_ALL variable to a locale which is not present 
on your system (i.e. the locale call would just return NULL in that 
case), thus if say you have a system, which still uses "iz_IL" instead 
of "he_IL" you couldn't set it your locale "he_IL".

So if you think Common::String + POSIX style locale return suffices, 
feel free to change it.

// Johannes




More information about the Scummvm-devel mailing list