Proposal: SDL_PreferredLocales()

icculus · October 21, 2012, 10:03pm

It’s not cruft; there are small but important differences between US and
UK English, and trust me, yanks notice when “color” is spelled with a
’u’. When you get into things like Chinese, these differences can be
even more significant.

Granted, a lot of games do what is called a “FIGS” translation (French,
Italian, German, Spanish), and if you happen to be in Quebec or Paris or
Senegal, French is probably “good enough” … it depends on the game,
really. These games can just take the first two characters (or the
language section, if we split it up into two strings), ignoring the
country code. It’s easy to supply the extra data, and easy to ignore it
if you don’t care, so it’s not worth stripping it out.

However, you are absolutely right that we should pick a standard instead
of saying “it might be two or three characters, oh well!!” Normalizing
this makes a great deal of sense.

–ryan.On 10/21/2012 02:13 PM, Andreas Schiffler wrote:

In my view the focus should be on “language” (ISO 639
http://en.wikipedia.org/wiki/ISO_639 is a standardized nomenclature
used to classify all known languages) rather than locale.

So the API would return “en” for any device that is set to operate
primarily in “English” and drop the US/GB/etc cruft.

Michael_Henning · October 21, 2012, 10:11pm

The way we do this on Windows in the GIMP is using
GetUserDefaultUILanguage, and then using a lookup table to convert
that to a locale string.

We then have our own UI to override that locale if the user chooses,
because it’s all such a mess on windows.

This post has some good information on locales in windows:
http://blogs.msdn.com/b/michkap/archive/2007/04/15/2146890.aspx

– drawocOn Sun, Oct 21, 2012 at 5:21 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:

That looks more like those programs are looking in the wrong place

Found what seems would be our relevant function, but…
http://msdn.microsoft.com/en-us/library/windows/desktop/dd318139(v=vs.85).aspx
…apparently it was only introduced on Vista, and SDL still supports
XP, doesn’t it?

What was meant to be used before Vista? Or maybe there wasn’t any
suitable way to retrieve a list so programs had to guesswork? Because
I don’t recall there ever being a way to specify the preferred
languages in XP and earlier, just the current language.

2012/10/21 Rainer Deyke :

On 2012-10-21 05:02, Ryan C. Gordon wrote:

I want to add a new API that reports the current user’s locale,
sincethis needs platform-specific code for Windows, Unix, and

Mac OS X (and perhaps Android/iOS have their own, too?).

Sounds good, but I am worried about the Windows implementation. Lots of
Windows programs (e.g. subversion) incorrectly assume that Japanese is my
preferred locale just because I have set Japanese as my language for
non-Unicode programs. Others incorrectly assume that I want to use German
because my location is set to Germany. My actual preference is to use
English whenever English is the “native” language of the program.

Still, even a flawed “best guess” is better than nothing.

–
Rainer Deyke (rainerd at eldwood.com)

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · October 21, 2012, 10:14pm

What was meant to be used before Vista?

GetLocaleInfo().

http://msdn.microsoft.com/en-us/library/windows/desktop/dd318101(v=vs.85).aspx

This…

 char lang[16], country[16];
 GetLocaleInfoA(LOCALE_USER_DEFAULT, LOCALE_SISO639LANGNAME,
                lang, sizeof (lang));
 GetLocaleInfoA(LOCALE_USER_DEFAULT, LOCALE_SISO3166CTRYNAME,
                country, sizeof (country));
 printf("%s_%s", lang, country);

…will print “en_US” on my machine. Works back to Windows 98. Win95 has
these functions, but reports failure because it doesn’t know about
LOCALE_SISO*NAME.

The Vista API you mentioned is a much better idea, though; I didn’t know
about it. We can certainly fall back to what I listed above if we’re on XP.

–ryan.

Piotr_Drapich · October 21, 2012, 11:09pm

This is not a very good idea - for instance Chinese will be represented by
"zh" only, while there can be a number of different Chinese languages to
choose from, most common being Chinese Simplified (zh-Hans) and Chinese
Traditional (zh-Hant) which do not translate well to a specific country of
ISO 3166.
The naming convention of Chinese follows ISO 15924 standard for script
names but I dont know how it could be used here…

P.On Sun, 21 Oct 2012, Andreas Schiffler wrote:

For an application developer the proposed use of two code and string
formats is not very helpful. It would make reliable language detection
much more work and/or error prone. Such logic needs to be absorbed by SDL.

A better API would “normalize” whatever it detects into a list of one of
the 139 official ISO-639-1 two letter codes
(http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes).

–Andreas

On 10/20/2012 8:02 PM, Ryan C. Gordon wrote:

I want to add a new API that reports the current user’s locale, since this needs platform-specific code for Windows, Unix, and Mac OS X (and perhaps Android/iOS have their own, too?).

Attached is a first shot at this. Here’s the documentation for the proposed function:

/**

Report the user’s preferred locales.

This returns an array of null-terminated strings with a NULL pointer to

mark the end of the array. The memory allocated for this return value is

owned by SDL, and should not be freed by the application; the returned

pointers remain valid until SDL_Quit() is called.

Returned strings are in the format xx, where ‘xx’ is an ISO-639 language

specifier (such as “en” for English, “de” for German, etc), or the format

xx_YY, where “YY” is an ISO-3166 country code (such as “US” for the United

States, “CA” for Canada, etc). Please note that not all of these codes are

2 characters; some are three or more.

The returned list of strings are in the order of the user’s preference.

For example, a German citizen that is fluent in US English and knows

enough Japanese to navigate around Tokyo might have a list like:

{ “de”, “en_US”, “jp”, NULL }. Someone from England might prefer British

English (where “color” is spelled “colour”, etc), but will settle for

anything like it: { “en_GB”, “en”, NULL }.

Most OSes only supply a single result; some, like Mac OS X, offer users

a way to prioritize a list of languages.

This function returns NULL on error, including when the platform does not

supply this information at all.

\return array of languages, NULL on error.
*/
extern DECLSPEC const char ** SDLCALL SDL_PreferredLocales(void);

Comments?

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Gabriel_Jacobo · October 22, 2012, 1:22am

2012/10/21 Ryan C. Gordon

I want to add a new API that reports the current user’s locale, since this
needs platform-specific code for Windows, Unix, and Mac OS X (and perhaps
Android/iOS have their own, too?).

extern DECLSPEC const char ** SDLCALL SDL_PreferredLocales(void);

Comments?

This looks great, my one nitpick would be returning an array of SDL_Locale
structs with:

char language[3]
char country[3]

Where country can be “”, so the hassle of determining if the country part
of the string is present is simplified a great deal, and it’s also easier
to ignore for those that don’t care about such nuances (which for example
for Latin American spanish vs the Spain variant are quite noticeable).–
Gabriel.

Jared_Maddox · October 22, 2012, 9:35am

Message-ID:
<CAEyBR+V17SEUqNxxXTcCNkX2vLE639bNi+q=Wgz6PAiz3e6dtQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

If the locale changes, I’d say trigger an event and then just let the
program call SDL_PreferredLocales() again to retrieve the new list
(why do we need a different function?).

The new function was intended as a possible alternative, not as part
of the event proposal.

Actually, coming to think on it, the above would not be thread-safe
since the list is allocated only once globally, meaning that even if
the list didn’t change until the function is called, once it is the
list will change for all threads without them knowing at all… What
should be done about this?

I’d say that’s up to the app’s developer. I consider it roughly the
same as the program trying to use the locale data BEFORE calling
SDL_PreferredLocales. Fortunately SDL already has atomic operations
wrappers, so it shouldn’t be TOO hard to deal with (or at least, no
harder than any other atomic stuff is).

Also, I was figuring that SDL would only update the locale string when
prompted by the program.> Date: Sun, 21 Oct 2012 04:59:35 -0300

From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()

Date: Sun, 21 Oct 2012 07:52:35 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID: <0657A41E-E31E-4C6A-881D-B56E384BFD66 at icculus.org>
Content-Type: text/plain; charset=us-ascii

Can you think of a realistic situation where someone says “it’s my turn to
play this game in a foreign language, so I’m going to change a setting in
the system control panel and not restart the app”?

I wasn’t thinking about games when I wrote that, I was thinking about
control panels (and anything else that can be expected to run for
multiple shifts without being turned off). And for that matter, it was
largely a ‘what corner-cases does this have?’ train of thought
anyways. The main reason why I even asked was to generate some
discussion on it (I don’t think I would pay attention to a locale
change, and mostly I would use this system as a installer/first
boot/configuration panel tool).

It’s sort of like the Unix philosophy on utilities: do one thing, and
do it well. If you’re going to do locales, then you might as well do
them well.

It’s a lot of complexity, especially since none of Mac OS X, Linux, or
Windows has an event to notify you of this change, and Unix systems are
checking an environment variable which can’t change.

To be honest, I was assuming that any such event and/or function would
be a placeholder until someone needed it. Because honestly, do people
normally do profiling to figure out what events they actually see, or
do they just deal with the ones that they CARE about?

Also, what about some ‘locale equality’ and 'locale_equivalence’
functions? Especially for programs that store their text (and/or
sound/graphics/etc.) outside of their actual executable, such
functions could be very convenient for choosing between different
versions of resources.

What would we be comparing? To see if “en_GB” and “en_US” are both the same
language, for example?

Equality would check for whether things were identical (“en_GB” and
"en_US" would presumably both be identical to “en”, but NOT to each
other), equivalence would check whether things were ‘close enough’
(“en_GB” and “en_US” WOULD both be equivalent).

For the use case, imagine that you’ve downloaded a demo that only has
"en_GB" resources, and your locale is set to “en_US”. A simple string
comparison would leave you unable to play the game, because it
couldn’t load any of it’s needed resources.

Date: Sun, 21 Oct 2012 13:12:26 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
Content-Type: text/plain; charset=us-ascii

It’s a lot of complexity, especially since none of Mac OS X, Linux, or
Windows has an event to notify you of this change

Brief followup: it turns out Mac OS X does:
NSCurrentLocaleDidChangeNotification, as of 10.5. But I feel my points still
stand.

–ryan.

So, it’s a one-event or 2-3 function change? I’m not impressed with
the difficulty of that, but I’m not worked up about it one way or
another, do what makes the most sense to you. If someone else really
cares, then they can either chime in, or do something later.

Date: Sun, 21 Oct 2012 15:16:15 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<CAEyBR+X19mx4KxBdcx_8AKKc9HY72A_NE6veSu+qaR6VHdx1Yg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

The problem is that many programs include separate translations
adapted for each locale so if you’re adding this you probably want
them to know the full locale, not just the overall language.

Agreed, that’s why I suggested the equality/equivalence testing
functions. Might as well have such simple and commonly relevant
functions inside SDL (and if it requires a comparison table instead of
simple string comparisons, then that’s even more reason to put it in
SDL).

Date: Sun, 21 Oct 2012 11:26:22 -0700 (PDT)
From: Mason Wheeler
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<1350843982.87486.BPMail_high_carrier at web122501.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=us-ascii

Why are we talking about locale and SDL?

Because we hate you? Or was it that you hate us? It can be so
difficult to tell when you essentially say that SDL 2 should have
fewer features than SDL 1.2. Most of us aren’t looking for a
multimedia-only library, we’re looking for a ‘thin’ (a.k.a. a simple)
library that doesn’t add layer upon layer of cruft that slows you down
and clouds the waters without providing an improved programming
environment.

And frankly, if I DID want a minimalist library then I would just
IGNORE the rest instead of complaining about it.

What does that have to do with.
SDL’s purpose, which is providing a multimedia development API? Locale is a
standard library-level piece of functionality; it ought to already be
available to developers. Do we really need to reinvent the wheel like
this?

Ultimately, SDL is less a simple media library, and more a simple
cross-platform library. It doesn’t focus on multi-media (in fact, if
it did then SDL_image would probably be built-in, as would a video
decoder, etc.), it focuses on being a simple multi-OS platform.
Sometimes things aren’t 100% cross-platform (DirectX and the hooks for
e.g. iOS), but what CAN be done well is.

Date: Sun, 21 Oct 2012 15:36:06 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<CAEyBR+X7XNf2zv5GcjpTKBwC_fD6mdPbKkCQJotRcVtrxR9H8g at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

I don’t recall the standard library ever providing a full list of all
the languages the system supports, sorted by the priority on which the
user wants to use them. Not even in POSIX.

I don’t think that’s what Mason was saying. Mason seems to want SDL to
be extremely minimalist, and as a general rule of thumb is opposed to
anything that isn’t directly related to graphics or audio. To be
honest, I think that if he got his way then SDL would mostly be
ignored by developers, since that’s not all that people need.

Date: Sun, 21 Oct 2012 21:30:32 +0200
From: Marcus von Appen
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID: <20121021193032.GA2140 at medusa.sysfault.org>
Content-Type: text/plain; charset=“us-ascii”

And why do you cut off the extra
information (e.g. encoding)?

Is the encoding specified with a similar standard document? I
wouldn’t want to deal with specifying it myself.
Does the encoding need to be specified? SDL doesn’t provide a way
to create text terminals, so if you’re using them you’re dealing with
special stuff anyways.
As I best recall, SDL’s font rendering library ALWAYS uses UTF-8,
so there’s no real point in asking for what encoding you’ll be using
there.
Files will be encoded in whichever encoding they use, and if you
support several then you should provide the user with a way to select
the one that gets output.

And the last: setlocale() is a C99 standard function, why is not that
one used in (at least) the POSIX implementation, and ideally in most of
the implemenetations?

Wasn’t POSIX’s first specification released in the early 90’s, or even
the 80’s? And aren’t the later specifications half-way ignored if you
aren’t paying for certification? I’d guess that’s why.

Date: Sun, 21 Oct 2012 15:36:43 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Cc: “sdl at lists.libsdl.org”
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
Content-Type: text/plain; charset=us-ascii

Threading is about equally as standard, should we remove that too?

–ryan.

Mason’s the type to say ‘yes’, so I’m surprised that you asked.

Date: Sun, 21 Oct 2012 16:41:23 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<CAEyBR+X=QZFQ3PhOKBdetcZeJG1nQbYEUb923mdzdiBKyvS=Uw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

That said, can somebody tell me what standard function allows one to
retrieve the list of preferred locales? I don’t know of any such
function.

As has been said, Mason probably wasn’t talking about a standard C
function, but instead OS specific functions or functions from other
libraries. There is a somewhat related function from the C library
(called setlocale), but it can’t be counted on to specify things any
particular way, and is largely intended to alter settings within the C
runtime library.

Mason basically wants SDL to include multimedia support, the stuff
required by that, and nothing else. I don’t think he’s highly rated
here, and if he took over the project for some reason then I think
someone would wind up forking it.

Date: Sun, 21 Oct 2012 12:54:42 -0700 (PDT)
From: Mason Wheeler
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<1350849282.34421.YahooMailNeo at web122503.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=“iso-8859-1”

That’s another one I sort of wonder about.? Why does SDL have its own thread
system?? Or atomic operations, or synchronization primitives?? Those are all
things that ought to be built into the standard library of any modern
language.?

C doesn’t have them yet, and I don’t recall if C++0x includes
synchronization primitives (nor do I know much about it’s atomics).
Besides, what’s in a standard library doesn’t actually matter to SDL
unless it’s in C’s standard library. Also, didn’t this conversation
already happen? I seem to remember Sam posting to the mailinglist that
he disagreed with your vision of SDL a few months ago.

But what do we need all the rest of this stuff for?? Isn’t the point of
using an external library to give you the ability to do new things??
Throwing in a bunch of stuff that we can already do seems kind of
pointless.

Hahaha! SDL isn’t about doing new things, it’s about doing things
easier than you otherwise could. I consider SDL inherently easier than
what I’ve experienced of e.g. Win32, and I dislike both Boost and SFML
(or whatever that was called).

SDL doesn’t do “new”, SDL does “easy”.

Date: Sun, 21 Oct 2012 17:15:43 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: Mason Wheeler , SDL Development List

Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<CAEyBR+UOMEu7Lbv1gc5MTktekdD6nC6tN__g+fjYseSSxhUoWA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Ironically I see no use for the streaming system, I’d rather use
something like PhysFS for that stuff (though it ended up biting me
back when I needed access outside the sandboxed filesystem…).

If you have the time then you might want to write an in-program
filesystem. I’ve played with doing that and it isn’t a big problem (it
requires a in-program filesystem library, a simple 'resource compiler’
to build a C file, and a simple ‘translating compiler’ to convert data
files into a C array representation). Once you have something like
that, it should be easy to extend it with e.g. external directories
and externally stored edits to “files”.

Date: Sun, 21 Oct 2012 18:03:59 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID: <5084714F.3010902 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 10/21/2012 02:13 PM, Andreas Schiffler wrote:

In my view the focus should be on “language” (ISO 639
http://en.wikipedia.org/wiki/ISO_639 is a standardized nomenclature
used to classify all known languages) rather than locale.

So the API would return “en” for any device that is set to operate
primarily in “English” and drop the US/GB/etc cruft.

It’s not cruft; there are small but important differences between US and
UK English, and trust me, yanks notice when “color” is spelled with a
’u’. When you get into things like Chinese, these differences can be
even more significant.

Here’s another point: US dollars vs. British (or English?) pounds.

Granted, a lot of games do what is called a “FIGS” translation (French,
Italian, German, Spanish), and if you happen to be in Quebec or Paris or
Senegal, French is probably “good enough” … it depends on the game,
really. These games can just take the first two characters (or the
language section, if we split it up into two strings), ignoring the
country code. It’s easy to supply the extra data, and easy to ignore it
if you don’t care, so it’s not worth stripping it out.

Also, you could do an initial release with just the 'generic’
translations, and later do customized translations according to
demand.

Date: Sun, 21 Oct 2012 18:11:37 -0400
From: drawoc
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<CAAgWFh3n7adkuJnw+Pk2D=ab-o5b-e1auyYE_Qv9kQU7jBVEyQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

The way we do this on Windows in the GIMP is using
GetUserDefaultUILanguage, and then using a lookup table to convert
that to a locale string.

We then have our own UI to override that locale if the user chooses,
because it’s all such a mess on windows.

Though personally, I’d say the override is a good design even if the
OS does things right.

Alex_Barry · October 22, 2012, 1:11pm

All flame wars aside, I think most of the issues that are being discussed
really go out of scope of what Ryan has presented, and let me tell you why.

First, most of the issues that have been presented (like locale changes
during execution time, firing an event, etc.) are not really in the scope
of SDL, however, I believe locale setting in general is. The idea with
this is that the programmer can now have a reliable function to get locale
information, and that’s all Ryan presented, and I think that is solid. I
think that since X.org does not have a locale change event that it would
be considered not a cross-platform functionality, and therefore does not
belong in SDL.

Second, the end-programmer (not SDL) should be able to decide when it’s
appropriate to check for locale changes, and how to deal with en_GB versus
eb_US. If any programmer cannot do this, then they should not be writing
multi-language apps. There is overlap with this and a presented issue
(what if the platform only supports en_GB, but my locale is set to en_US)

this is something the programmer needs to deal with, not SDL. I think it
would be pretty easy to implement something application side that goes
something like if ( GetApplicationAssets( “en_US”) == NULL ) {
GetApplicationAssets( GetClosestLocale(“en”) ); }
It wouldn’t be trivial at all.

One suggestion I liked (but I can’t seem to find) is having the two pieces
of information separated, so rather than:

extern DECLSPEC const char ** SDLCALL SDL_PreferredLocales(void);

It could be something like:

typedef struct {
const char *language;
const char *region;
} SDL_Locale;

extern DECLSPEC const SDL_Locale* SDLCALL SDL_PreferredLocales(void);

I can’t really foresee anyone sharing an application with another person
during runtime that would require any sort of language swap. Maybe I just
live in the wrong neck of the woods, but any of my friends who know more
than one language typically stick with english for their OS locale setting.

To deal with any sort of anomaly, dealing with specific application locales
should be an application issue, not an OS issue - getting the preferred
locale should never set in stone the locale of the application, just a
guess to get it running and the user should be able to change it from
inside the application, and that should be smart enough to know if your
application supports your language, and be able to load your assets
appropriately.

-Alex

Alex_Barry · October 22, 2012, 1:15pm

Somehow I couldn’t english at the end of that (last paragraph):

To deal with any sort of anomaly, dealing with specific application locales
should be an application issue, not an SDL issue - getting the preferred
locale should never set in stone. The locale of the application should be
just a guess to get it running and the user should be able to change it
from inside the application, and that should be smart enough to know if
your application supports your language, and be able to load your assets
appropriately.On Mon, Oct 22, 2012 at 9:11 AM, Alex Barry <@Alex_Barry> wrote:

All flame wars aside, I think most of the issues that are being discussed
really go out of scope of what Ryan has presented, and let me tell you why.

First, most of the issues that have been presented (like locale changes
during execution time, firing an event, etc.) are not really in the scope
of SDL, however, I believe locale setting in general is. The idea with
this is that the programmer can now have a reliable function to get locale
information, and that’s all Ryan presented, and I think that is solid. I
think that since X.org does not have a locale change event that it
would be considered not a cross-platform functionality, and therefore does
not belong in SDL.

Second, the end-programmer (not SDL) should be able to decide when it’s
appropriate to check for locale changes, and how to deal with en_GB versus
eb_US. If any programmer cannot do this, then they should not be writing
multi-language apps. There is overlap with this and a presented issue
(what if the platform only supports en_GB, but my locale is set to en_US)

this is something the programmer needs to deal with, not SDL. I think it
would be pretty easy to implement something application side that goes
something like if ( GetApplicationAssets( “en_US”) == NULL ) {
GetApplicationAssets( GetClosestLocale(“en”) ); }
It wouldn’t be trivial at all.

One suggestion I liked (but I can’t seem to find) is having the two pieces
of information separated, so rather than:

extern DECLSPEC const char ** SDLCALL SDL_PreferredLocales(void);

It could be something like:

typedef struct {
const char *language;
const char *region;
} SDL_Locale;

extern DECLSPEC const SDL_Locale* SDLCALL SDL_PreferredLocales(void);

I can’t really foresee anyone sharing an application with another person
during runtime that would require any sort of language swap. Maybe I just
live in the wrong neck of the woods, but any of my friends who know more
than one language typically stick with english for their OS locale setting.

To deal with any sort of anomaly, dealing with specific application
locales should be an application issue, not an OS issue - getting the
preferred locale should never set in stone the locale of the application,
just a guess to get it running and the user should be able to change it
from inside the application, and that should be smart enough to know if
your application supports your language, and be able to load your assets
appropriately.

-Alex

Tim_Angus · October 22, 2012, 1:27pm

Agreed.On 22/10/2012 14:11, Alex Barry wrote:

One suggestion I liked (but I can’t seem to find) is having the two
pieces of information separated, so rather than:
extern DECLSPEC const char ** SDLCALL SDL_PreferredLocales(void);
It could be something like:
typedef struct {
   const char *language;
   const char *region;
} SDL_Locale;

extern DECLSPEC const SDL_Locale* SDLCALL SDL_PreferredLocales(void);

Gabriel_Jacobo · October 22, 2012, 1:53pm

2012/10/22 Tim Angus > On 22/10/2012 14:11, Alex Barry wrote:

One suggestion I liked (but I can’t seem to find) is having the two
pieces of information separated, so rather than:
extern DECLSPEC const char ** SDLCALL SDL_PreferredLocales(void);
It could be something like:
typedef struct {
   const char *language;
   const char *region;
} SDL_Locale;

extern DECLSPEC const SDL_Locale* SDLCALL SDL_PreferredLocales(void);
Agreed.

I suggested that, it seems easier to work with, specially if we allow
region/country to be null. You can use this suggestion freely as long as I
get a royalty of 1 USD per use

–
Gabriel.

Andreas_Schiffler · October 22, 2012, 2:52pm

Thumbs up for this one as well … particularly useful if language is
normalized/guaranteed to be one of the 139 official ISO-639-1 two letter
codes.On 10/22/2012 6:11 AM, Alex Barry wrote:

It could be something like:

typedef struct {
  const char *language;
  const char *region;
} SDL_Locale;

extern DECLSPEC const SDL_Locale* SDLCALL SDL_PreferredLocales(void);

slouken · October 22, 2012, 6:27pm

Yup, agreed, both on the struct and the normalization. Looks good Ryan!

For context, SDL was born as a platform independent wrapper around system
interfaces for porting games and multimedia applications. It’s currently
being used at Valve to port games to Linux (yay!)

Lots of people use it for making all kinds of programs, but making porting
of games easy is the heart of what SDL is all about, and we’re going to
make it even easier to meet these goals.

We are sensitive to code bloat and other things that game developers care
about, so we’re making sure that any new functionality is something you can
ignore, and focus on what’s really important to you.

Cheers!On Mon, Oct 22, 2012 at 7:52 AM, Andreas Schiffler wrote:

On 10/22/2012 6:11 AM, Alex Barry wrote:

It could be something like:

typedef struct {
const char *language;
const char *region;
} SDL_Locale;

extern DECLSPEC const SDL_Locale* SDLCALL SDL_PreferredLocales(void);

Thumbs up for this one as well … particularly useful if language is
normalized/guaranteed to be one of the 139 official ISO-639-1 two letter
codes.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Gabriel_Jacobo · October 22, 2012, 6:38pm

2012/10/22 Sam Lantinga

Yup, agreed, both on the struct and the normalization. Looks good Ryan!

For context, SDL was born as a platform independent wrapper around system
interfaces for porting games and multimedia applications. It’s currently
being used at Valve to port games to Linux (yay!)

Lots of people use it for making all kinds of programs, but making porting
of games easy is the heart of what SDL is all about, and we’re going to
make it even easier to meet these goals.

We are sensitive to code bloat and other things that game developers care
about, so we’re making sure that any new functionality is something you can
ignore, and focus on what’s really important to you.

Cheers!

If I may risk the anger of the minimalist gods and abuse Ryan a bit, it
just occured to me that some sort of language enum based on the ISO
standards would be a nice thing to have (something like SDL_LANG_EN,
SDL_LANG_ES, etc)…handy to add in the SDL_Locale struct and easier to
make a switch/case with.–
Gabriel.

Sik_the_hedgehog · October 22, 2012, 6:45pm

2012/10/22 Sam Lantinga :

For context, SDL was born as a platform independent wrapper around system
interfaces for porting games and multimedia applications. It’s currently
being used at Valve to port games to Linux (yay!)

Reminds me about how it took me some time to realize I communicated to
somebody worked in Valve XD Hopefully some day I’ll get my game on
Steam. Actually, the fact it works on Linux and isn’t really demanding
GPU-wise (which means it should work fine on most Linux systems even
with current drivers) may make it a good deal for Steam for Linux’s
early catalog…

Anyway, enough off-topic, let’s get back on track:

2012/10/22 Gabriel Jacobo :

If I may risk the anger of the minimalist gods and abuse Ryan a bit, it just
occured to me that some sort of language enum based on the ISO standards
would be a nice thing to have (something like SDL_LANG_EN, SDL_LANG_ES,
etc)…handy to add in the SDL_Locale struct and easier to make a
switch/case with.

It’s a double-edged sword, first because we never know when the
language codes may change, and second because it’s possible that if
you already have organized everything by strings (e.g. filenames) it’s
probably easier to keep dealing with strings. I guess this was Ryan’s
original intention.

Maybe do both an enum and also provide a mapping of strings for the values?

icculus · October 22, 2012, 6:58pm

Maybe do both an enum and also provide a mapping of strings for the values?

There’s not much sense in having both.

I’m inclined to leave it as strings, though. That way every time they
decide to change the standard, we don’t have to update the header files.

…or have gigantic enum in the headers at all.

–ryan.

Alex_Barry · October 22, 2012, 7:01pm

I am inclined to think enums are also a waste, for the same reasons Ryan
mentioned, and as Sik said, we’re going to be dealing with strings for
files and directories anyway.On Mon, Oct 22, 2012 at 2:58 PM, Ryan C. Gordon wrote:

Maybe do both an enum and also provide a mapping of strings for the

values?

There’s not much sense in having both.

I’m inclined to leave it as strings, though. That way every time they
decide to change the standard, we don’t have to update the header files.

…or have gigantic enum in the headers at all.

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Dave5 · October 22, 2012, 9:23pm

I actually think my objection is completely ridiculous (incidentally,
I like the api, particularly it’s simplicity), but I’ll say it
anyways: what if the user CHANGES their locale settings while a
program is running?

Can you think of a realistic situation where someone says “it’s my turn
to play this game in a foreign language, so I’m going to change a
setting in the system control panel and not restart the app”?

Ryan,

I do know of one case where I’ve seen this first hand. My wife is from
Quebec and she is constantly switching back and forth between locales for
keyboard layout – so that she can google something in English or French
as desired, for example.

One could imagine that this might come into play for in-game chat
functionality. Of course, in order to be useful this hypothetical chat
would also need to be able to switch locales as well, and that is beyond
the scope of what you’re proposing. But, I wanted to throw this
experience out there in case it is useful.

DaveOn Sun, 21 Oct 2012, Ryan C. Gordon wrote:

Jared_Maddox · October 23, 2012, 12:09am

Message-ID:
<CAKDfesmXa2VTb3Ek7xOCAuy4WD=kSN_txdiTdK+HDHLL78KqmQ at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

If I may risk the anger of the minimalist gods and abuse Ryan a bit, it
just occured to me that some sort of language enum based on the ISO
standards would be a nice thing to have (something like SDL_LANG_EN,
SDL_LANG_ES, etc)…handy to add in the SDL_Locale struct and easier to
make a switch/case with.

I suppose that this could be done by taking the ISO character sequence
for a language (e.g. “en”) and converting the ascii encoding to an
integer (e.g. 0x6E65 or 0x656E for “en” ).

However, you really probably shouldn’t be hard-coding locales.> Date: Mon, 22 Oct 2012 15:38:38 -0300

From: Gabriel Jacobo
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()

Date: Mon, 22 Oct 2012 15:45:22 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
<CAEyBR+XA6+tKwWjC-Fg5k6H7PuNX0PF_+_Eq4Z6FHXDTT6uHcA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2012/10/22 Gabriel Jacobo :

If I may risk the anger of the minimalist gods and abuse Ryan a bit, it
just
occured to me that some sort of language enum based on the ISO standards
would be a nice thing to have (something like SDL_LANG_EN, SDL_LANG_ES,
etc)…handy to add in the SDL_Locale struct and easier to make a
switch/case with.

It’s a double-edged sword, first because we never know when the
language codes may change, and second because it’s possible that if
you already have organized everything by strings (e.g. filenames) it’s
probably easier to keep dealing with strings. I guess this was Ryan’s
original intention.

I think it would also be simply better to keep it all as strings.

Date: Mon, 22 Oct 2012 14:58:09 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Message-ID: <50859741.1040708 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Maybe do both an enum and also provide a mapping of strings for the
values?

There’s not much sense in having both.

I’m inclined to leave it as strings, though. That way every time they
decide to change the standard, we don’t have to update the header files.

What would they change in the standard, some numerical identifier?
Order of listing?

Sik_the_hedgehog · October 23, 2012, 2:03am

2012/10/22 Jared Maddox :

What would they change in the standard, some numerical identifier?
Order of listing?

Probably adding new codes and then having some OS support it. If we
went with enums then SDL wouldn’t be able to recognize those new
codes. By using strings we futureproof SDL as it doesn’t need to know
about them at all.

icculus · October 23, 2012, 2:58am

What would they change in the standard, some numerical identifier?
Order of listing?

Well, they’ve already realized that zh_TW (Chinese in Taiwan) was a really crappy way to say “Traditional (not Simplified) Chinese”

Which is why Mac OS X reports this as “zh-Hant” now.

–ryan.