Re: Re(2): Application localization
Re: Re(2): Application localization
- Subject: Re: Re(2): Application localization
- From: Douglas Davidson <email@hidden>
- Date: Thu, 6 Dec 2001 15:46:36 -0800
On Thursday, December 6, 2001, at 10:33 AM, Jens Bauer wrote:
% defaults read NSGlobalDomain AppleLanguages
(English, German, French, Dutch, Italian, Japanese, Spanish)
Now I open System Preferences. I click "International". I add "Dansk"
(danish)
I close System Preferences, and try the command again:
% defaults read NSGlobalDomain AppleLanguages
(en, de, fr, nl, it, ja, es, da)
Will this mean anything to developers, or does Mac OS X know that da is
"Dansk" ?
The ISO language abbreviations (e.g., en) are actually the recommended
format for specifying localizations; for region-specific localizations,
use the language abbreviation + country abbreviation format (e.g.,
en_US). However, language names (e.g. English) are supported for
compatibility reasons. You should be able to use whichever you prefer.
See the Bundle Services documentation for more information.
I've looked into most of the localized strings in TextEdit, and found
that they
use the format
"oldstring" = "newstring"
I also noticed in the Cocoa application project, you get a
"InfoPList.strings" by
default. Looking into this, I see the format
Identifier = "string"
I'd like to ask how I should refer to this string. Do I need to tell the
compiler
where to find it, or can I just use the Identifier directly from
NSString
somehow ?
I'm thinking about situations where you can have 3 strings that look the
same, but
mean something different.
"Play" = "Play" /* play the tape for instance */
"Play" = "Play" /* a game (translate "Game" into french and back, you'll
get "Play") ;) */
"Play" = "Play" /* a play at the theater */
The keys can be whatever you like; they don't have to be the
development-localization version of the strings, that's just a common
convention. Obviously if you needed to disambiguate multiple instances
of the same string, you would need to use something else. However, this
is less common than you might think; short strings often occur in common
situations such as menu titles where they should have identical
translations, and other strings tend to be longer and less ambiguous.
Douglas Davidson