Re: Using XCode and en.lproj vs. English.lproj
Re: Using XCode and en.lproj vs. English.lproj
- Subject: Re: Using XCode and en.lproj vs. English.lproj
- From: "Alexey Proskuryakov" <email@hidden>
- Date: Sun, 26 Jun 2005 12:20:00 +0400
On Sun, 26 Jun 2005 00:56:12 +0200 Greg Hurrell <email@hidden> wrote:
What makes you think so, the .ru domain of my e-mail address? ;-)
No, your defense of an English-centric display pattern in the user
interface does; I didn't even look at the domain.
Sure, English is better than the two-letter ISO codes exposed to the user -
noone in the world speaks ISO natively :)
Even as a developer, I would like Xcode to hide these codes from me
(although that's of course less important).
Apple has been advising developers to use the ISO folder names for years
now. The sooner Xcode is brought into compliance with Apple's long-standing
recommendations the better, regardless of how long it takes for them to
implement a properly localized display in the Finder.
But why? Apple may well switch to three-letter ISO language codes before
Finder gets support for displaying localized language names :). There are a
lot of things that should and will be eventually changed (the politically
incorrect zh_TW and zh_CN codes, for example).
Besides, it is equally easy to translate English.lproj or en.lproj into
"Anglais" (there's already an exposed API that turns any language designator
into an ISO one).
Currently, I have no use for it in my code, but if you do, please
file an enchancement request. It is always better to provide
potential use cases and explain the need (there are some subtle
questions with such an API, which may explain why they haven't
exposed it).
I suspect they do have a private but not-yet exposed API which they're
using in the International preferences pane. That's a pretty good example of
a use case.
My point is that this internal API is most certainly incomplete. When it
was first introduced to ICU, it appeared OK, but the moment Apple had a real
use case, critical omissions became obvious. They were eventually fixed (very
recently), but who can be so sure that the second use case won't highlight
another unforeseen problem?
One doesn't expose work in progress without a very good reason.
- WBR, Alexey Proskuryakov
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden