[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