RE: US/non-US localization problem
RE: US/non-US localization problem
- Subject: RE: US/non-US localization problem
- From: "David Hazel" <email@hidden>
- Date: Wed, 16 May 2007 23:17:20 +0100
- Importance: Normal
Thanks for all of the suggestions.
I've opted for a solution which ignores both localization and locale, as far
as showing support information is concerned. As has been suggested, these
don't really relate to what the software needs to know, to decide what
information to show. In fact, it is neither a question of where the software
thinks it's running nor one of where the user thinks s/he is: it's to do
with where the software was obtained (which supply channel). Thus, it's a
configuration control problem, to which I've applied a corresponding
solution: macros, conditional compilation directives and multiple build
configurations.
David Hazel
-----Original Message-----
From: Deborah Goldsmith [mailto:email@hidden]
Sent: 16 May 2007 22:44
To: Douglas Davidson
Cc: David Hazel; 'Apple CocoaDev list (E-mail)'
Subject: Re: US/non-US localization problem
In addition to Doug's wise words I will add that the system *does*
keep track of your location, via the Time Zone preference in the Date
& Time preference in System Preferences, but there is no public,
supported way to get this information. The system also keeps track of
the country which was chosen in Setup Assistant (which may not be the
country the system is currently located in); again, there is no
public way to get this information. You might want to file a bug if
you need this.
Another option is to look at the ID of the current time zone and try
to figure out where the user is from that. It's probably easier to
follow Doug's suggestion of looking at the country code of the
current locale as a first approximation. It will be correct most of
the time.
Deborah Goldsmith
Internationalization, Unicode liaison
Apple Inc.
email@hidden
On May 15, 2007, at 12:42 PM, Douglas Davidson wrote:
>
> On May 15, 2007, at 12:15 PM, David Hazel wrote:
>
>> But I'm still confused. Is there a difference between locale and
>> localization? I have always understood "locale" to be where the
>> system thinks it is (including language, units, formatting rules
>> and so on), and "localization" to be what has to be done to make
>> an application obey the locale rules. If the system thinks my
>> locale is en_US, why isn't it attempting to use the corresponding
>> language file, if it exists? If I have "English" as my language
>> and "United States" as my format, my "current locale" comes back
>> as "en_US". If, on the other hand, I set my language to "English"
>> and my format to "United Kingdom", my locale comes back as
>> "en_GB". However, both locales, for some reason, attempt to use
>> the generic "en" language rather than any locale-specific variant
>> that exists.
>>
>> Is "U.S. English" the default setting for a system running in the
>> United States? Because if not, I will need to do more to ensure
>> that US-based users see the correct support information. If a US-
>> based user selects the generic "English" language, rather than
>> "U.S. English" (which it seems to me they might well do), and sets
>> their format to be "United States", I would want them to see the
>> correct support information for the US. At the moment, they would
>> see information that would be correct for UK-based users. Is there
>> any way I can ensure this using the localization rules? Could I,
>> for instance, have a "en - en_US" localization? If so, how do I
>> name the corresponding localization in XCode? If I were to use
>> this localization instead of just "en_US", would it work in both
>> cases (i.e. "U.S. English" language OR "English" language +
>> "United States" format)?
>>
>
> There is a very significant difference between locale and
> localization.
>
> Localization refers to the language that an application uses to
> communicate with its users. The "en_US" localization refers to
> English as it is used in the United States; the "en_GB"
> localization refers to English as it is used in Great Britain. For
> example, an item in "en_US" localization might refer to "color"
> where an item in "en_GB" localization would refer to "colour".
>
> Locale, on the other hand, refers to a wide range of formatting
> choices for information mostly supplied by the user--things like
> dates, times, number formats, etc.; an "en_US" locale setting
> refers to the formatting typically used in the United States, while
> an "en_GB" locale setting refers to the formatting typically used
> in Great Britain. For example, an "en_US" locale setting might
> call for today's date to be written as 5/15, where an "en_GB"
> locale setting might call for it to be written as 15/5.
>
> On Mac OS X, localization and locale are separate decisions. The
> localization is determined by a list of choices ordered by user
> preference, shown in the "Language" tab of the International
> preference pane. The locale starts with a single basic choice--the
> first popup in the "Formats" tab of the International preference
> pane--that may be further customized as regards individual items,
> via the remainder of the items in the "Formats" tab.
>
> Neither localization nor locale is a good proxy for the physical
> location of the system. Localization is especially unsuitable for
> this; for example, Mac OS X ships with a single English
> localization rather than separate US and GB English localizations,
> and furthermore the English localization is likely to be used by
> many international users as a second choice, if Mac OS X does not
> ship with a localization for their first language.
>
> What I would recommend is this: definitely do not use localization
> for this purpose. The locale, as given by NSLocale/CFLocale, might
> provide a reasonable way of choosing a default for your app's
> notion of location, but nothing more; the fact that users choose US
> time and date formatting does not imply that they are located in
> the United States. Give users a chance to customize your app's
> notion of where they are located, and make it clear that the
> setting derived from locale information is only a default guess.
>
> Douglas Davidson
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden