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);
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.
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?
As I said, a ridiculous objection, but SDL (due to it’s cross-platform
nature) is the sort of thing to stick around for a long time, and with
SDL2’s multiwindow support I can see the possibility that it might be
used for long-uptime programs, so I figure that “before the API is
adopted” would be a good time to look at this.
Here’s a couple thoughts:
New event to indicate that the locale set has changed.
After either of those, of course, the program might have to deal with
a modified locale set, which in turn could result in a change of
locale pointer, but I think it’s worth discussing.
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.> Date: Sat, 20 Oct 2012 23:02:21 -0400
From: “Ryan C. Gordon”
To: “sdl at lists.libsdl.org List”
Subject: [SDL] Proposal: SDL_PreferredLocales()
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?).
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?
2012/10/21 Jared Maddox :>> Date: Sat, 20 Oct 2012 23:02:21 -0400
From: “Ryan C. Gordon”
To: “sdl at lists.libsdl.org List”
Subject: [SDL] Proposal: SDL_PreferredLocales()
Message-ID:
Content-Type: text/plain; charset=“us-ascii”
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.
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?
As I said, a ridiculous objection, but SDL (due to it’s cross-platform
nature) is the sort of thing to stick around for a long time, and with
SDL2’s multiwindow support I can see the possibility that it might be
used for long-uptime programs, so I figure that “before the API is
adopted” would be a good time to look at this.
Here’s a couple thoughts:
New event to indicate that the locale set has changed.
After either of those, of course, the program might have to deal with
a modified locale set, which in turn could result in a change of
locale pointer, but I think it’s worth discussing.
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.
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”?
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.
And it would be an event most apps wouldn’t check at all, and if they did, it would be a seriously undertested codepath.
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?
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.
–AndreasOn 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);
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.
To be clear, you would rather have this return “en_US” as “en” and “US” separately?
–ryan.On Oct 21, 2012, at 12:32 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.
–AndreasOn 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, Andreas Schiffler <@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.
To be clear, you would rather have this return “en_US” as “en” and “US” separately?
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.
2012/10/21 Andreas Schiffler :>
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
Why are we talking about locale and SDL? 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?------------------------------
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler :
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
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.
2012/10/21 Mason Wheeler :>
Why are we talking about locale and SDL? 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?
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler :
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
Why are we talking about locale and SDL? 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?
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.
That’s not the point here and to my understanding this is also not the
point of the initial proposal. The initial proposal targets on some sort
of wrapper around localeconv() and setlocale() to my understanding,
utilising the primary OS’s API for that purpose.
On that note to Ryan:
You should not only evaluate LANG on POSIX, but also LC_ALL and maybe
LC_MESSAGES as fallbacks, if LANG is not set. Also, please handle the C
and POSIX identifiers properly. And why do you cut off the extra
information (e.g. encoding)?
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?
Correct me if I am wrong, but the original proposal was an API that
could be used solve the following common developer scenario:
“Make it easy for SDL2 developers to customize a game for a specific
language in a cross-platform way.”
If that is the case, I think something like the following would be one
of the simplest code pattern folks would want to use:
switch (SDL_GetPreferredLocale()) {
case SDL_LocaleEN:
// Load English string resources and game assets
break;
case SDL_LocaleFR:
// Load French string resources and game assets
break;
case SDL_LocaleUnknown:
default:
// Load Klingon string resources and game assets
}
The original function API char** SDL_GetPreferredLanguages() is also
useful if it returns a known set of values (i.e. the 137 language codes)
as it would make it very easy to construct a resource filenames to
search for, for example.On 10/21/2012 11:36 AM, Sik the hedgehog wrote:
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.
2012/10/21 Mason Wheeler :
Why are we talking about locale and SDL? 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?
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler <@Andreas_Schiffler>:
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, Andreas Schiffler <@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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
Threading is about equally as standard, should we remove that too?
–ryan.On Oct 21, 2012, at 2:26 PM, Mason Wheeler wrote:
Why are we talking about locale and SDL? 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?
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler :
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
That can sound mean… though yeah, that’s the first thing I thought
too, SDL has support for threading when pthreads could do the job
(actually, how well is that supported on mobile platforms?).
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.
2012/10/21 Ryan C. Gordon :>
Threading is about equally as standard, should we remove that too?
–ryan.
On Oct 21, 2012, at 2:26 PM, Mason Wheeler wrote:
Why are we talking about locale and SDL? 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?
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler :
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
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.? The only utility functionality that I really see as justified is SDL’s streaming system (RWops) because it’s actually used by the core multimedia components and so it requires a unified interface.? And it’s done in such a way that it’s easy to wrap around the streams provided by your language of choice, so it doesn’t really get in the way.
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.________________________________
From: Ryan C. Gordon
To: SDL Development List
Cc: “sdl at lists.libsdl.org”
Sent: Sunday, October 21, 2012 12:36 PM
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Threading is about equally as standard, should we remove that too?
–ryan.
On Oct 21, 2012, at 2:26 PM, Mason Wheeler <@Mason_Wheeler> wrote:
Why are we talking about locale and SDL? 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?
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler :
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
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…). Again,
maybe some of this functionality doesn’t work well with the standards
when it comes to mobile platforms, something SDL needs to cope with,
so not sure.
Anyway: what is the function in the standard library that allows one
to retrieve the list of user preferred locales? I still don’t know
about any such function.
2012/10/21 Mason Wheeler :> 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. The only utility functionality that I really see as justified is
SDL’s streaming system (RWops) because it’s actually used by the core
multimedia components and so it requires a unified interface. And it’s done
in such a way that it’s easy to wrap around the streams provided by your
language of choice, so it doesn’t really get in the way.
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.
From: Ryan C. Gordon
To: SDL Development List
Cc: “sdl at lists.libsdl.org”
Sent: Sunday, October 21, 2012 12:36 PM
Subject: Re: [SDL] Proposal: SDL_PreferredLocales()
Threading is about equally as standard, should we remove that too?
–ryan.
On Oct 21, 2012, at 2:26 PM, Mason Wheeler wrote:
Why are we talking about locale and SDL? 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?
On Sun, Oct 21, 2012 11:16 AM PDT Sik the hedgehog wrote:
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.
2012/10/21 Andreas Schiffler :
In my view the focus should be on “language” (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.
–Andreas
On 10/21/2012 10:13 AM, Ryan C. Gordon wrote:
On Oct 21, 2012, at 12:32 PM, 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.
To be clear, you would rather have this return “en_US” as “en” and "US"
separately?
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.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?).
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.
Would it be possible if maybe, you know, you could just stop posting to
this list?On Sun, 21 Oct 2012 12:54:42 -0700 (PDT) Mason wrote:
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.? The only utility functionality that I really
see as justified is SDL’s streaming system (RWops) because it’s
actually used by the core multimedia components and so it requires a
unified interface.? And it’s done in such a way that it’s easy to
wrap around the streams provided by your language of choice, so it
doesn’t really get in the way.
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.
