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

[Max Horn]

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

Sure, there is the risk of a port returning malformed data, but the worst that can happens it that the default language is not correctly detected, and we fallback to english. Users then are not worse of than they are now. Plus, such a bug in a backend would hopefully be quickly reported and easily fixed.

Cheers,
Max

[*] <http://en.wikipedia.org/wiki/Locale#POSIX-type_platforms>
[**] <http://en.wikipedia.org/wiki/IETF_language_tag>



Am 27.11.2010 um 03:19 schrieb Johannes Schickel:

> On 11/27/2010 01:44 AM, Jordi Vilalta Prat wrote:
>> Hi,
>> 
>> 2010/11/25<lordhoto at users.sourceforge.net>:
>>> Revision: 54479
>>>          http://scummvm.svn.sourceforge.net/scummvm/?rev=54479&view=rev
>>> Author:   lordhoto
>>> Date:     2010-11-25 18:40:56 +0000 (Thu, 25 Nov 2010)
>>> 
>>> Log Message:
>>> -----------
>>> OSYSTEM: Add API to query the system locale.
>>> 
>>> I also adapted the SDL backend to implement the API.
>> Thanks for adding this, it's another step forward. However, there's
>> one annoyance: the addition of the
>> getLanguageLocale(parseLanguageFromLocale()) step adds the requirement
>> of the locale language to be present in the languages table in
>> utils.cpp. In my particular case it has caused the Catalan language
>> not to be auto-detected anymore, since it wasn't in the known
>> languages table.
>> 
>> It would be more flexible (as it was before) if getSystemLanguage()
>> returned a Common::String. If a backend needs manual language mapping,
>> the porter wouldn't mind having to return a string instead of an enum
>> value.
> 
> There is a (major) problem about returning a Common::String though: we 
> need to agree on a locale format. We could of course chose the more or 
> less simple way out and say we use Linux (POSIX?) style locales. In the 
> end if we use the system language for more than the translation code it 
> is definitely easier to have it return a Common::Language, that way we 
> could say auto select (select and not choose!) the game language of the 
> users system in case we have multiple detection entries for example.
> 
> // Johannes
> 
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> Scummvm-cvs-logs mailing list
> Scummvm-cvs-logs at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-cvs-logs
>