Re: [OFF] Localisation (was Re: Security Framework: authorization rights.)
Re: [OFF] Localisation (was Re: Security Framework: authorization rights.)
- Subject: Re: [OFF] Localisation (was Re: Security Framework: authorization rights.)
- From: Wade Tregaskis <email@hidden>
- Date: Tue, 4 Nov 2003 16:50:26 +1100
You're going to annoy your international users if you don't get your
localisations right.
Which you will do if you follow the protocols defined by the operating
system. I would encourage all developers to properly internationalise
their applications:
<http://www.stepwise.com/Articles/Technical/2003-04-03.01.html>
I'm not sure what article has to do with this issue specifically - it's
a good resource for localisation otherwise - but you've just reiterated
the point you're supposed to be arguing *against*. That page, as well
as all Apple's documentation, clearly defines how you should go about
localising your app. In fact, here's a tidbit from that link you
posted:
For some languages, there are regional variations (e.g. Standard vs.
Brazillian Portuguese). Apple recommends that you use pt.lproj for
non-region-specific Portuguese, and pt_PT.lproj and pt_BR.lproj for
region-specific localizations. Whenever you include a region-specific
locale, though, you should also include the non-region-specific locale
(for example, if you include either pt_PT.lproj or pt_BR.lproj, you
should include "pt.lproj"). If a resource has a value common to both,
for example pt_PT.lproj and pt_BR.lproj, then you can put it in
pt.lproj, and both pt_PT.lproj and pt_BR.lproj users will pick it up
from there. You can omit resources from the region-specific .lprojs,
but not from the non-region-specific ones.
Now, ideally what you should do is have "en", "en_US", "en_AU",
"en_UK", etc etc. Any strings which happen to not have any conflicts
(e.g. "Press Cancel to abort installation.") should go in "en". Any
strings which do conflict (e.g. "Please localise your apps properly.")
should go in the appropriate dialect. So, we should be seeing a heck
of a lot more apps with "en_US" in them. Personally, I've never seen
one.
Now, you can extend this further, although it becomes arguable. Since
Australian & UK English are largely the same, and since UK English is
by definition *the* English, you should probably put them into "en"
rather than waste space having two dialects which are for the vast
majority of cases identical. Any US specific strings can then go into
"en_US". So this way you conserve space, while catering for all the
major groups I can think of.
The only time you'd ever use "en_AU" or "en_UK", I imagine, is if you
want to include colloquialisms and culture references (e.g. "Strewth!"
or "Bobby", or cases like "jelly").
As it stands, most developers don't follow this, least of all Apple
themselves - they don't even ship an English dictionary with OS X. So,
as far as I've seen personally, there's about half a dozen developers
in the whole world following Apple's guidelines. And, again, not even
Apple is one of them.
Wade Tregaskis
-- Sed quis custodiet ipsos custodes?
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.