Re: Li18nux Locale Name Guideline Public Review
I've participated (as an observer) in Li18nux proceedings, and I have
to say I was not impressed in general. The best people are very good,
have lots of experience. But this is a very large-scale effort, and
(as of 18 months ago) they were taking all comers. Last I looked
(about 6 months ago) that showed in a lot of the product.
However, it's important to remember that a bad standard is better than
no standard. It is extremely difficult to change a bad standard, it
is true. But it's even harder to change "no standard", and in the
meantime users suffer much more.
If Debian i18n doesn't like the direction Li18nux is going, then I
suggest you (I'm an observer, here, too) participate. Telling the
relevant Li18nux/LSB working group "Debian has looked at the Li18nux
proposal. However, we intend to {use the IANA names, not impose
unstandardized names, deprecate IBM code pages to compatibility
packages} for these reasons: ...." would be great. The Debian name
commands a fair amount of respect because of Debian's continuing
commitment to standards, both international and internal.
>>>>> "David" == David Starner <starner@okstate.edu> writes:
David> It doesn't seem that the authors were very familiar with
David> the IANA names,
This is a typical problem with Li18nux, but not a showstopper. Point
that out, they'll come around.
David> Why all the IBM code pages? glibc currently supports two -
David> 1251 (be_BY, bg_BG) and 1255 (yi_US).
What do you mean by "support"? For code pages, I would say "iconv" is
the relevant functionality. On my box
tleepslib:/usr/local/src# iconv --list | grep ^CP | wc
90 90 748
David> Is there anyone who really needs all the others?
Yes. Anybody who wants to interoperate with the rest of the world,
which, like it or not, runs Windows. Eg, Samba. Samba is an
important example, because Japanese and Taiwanese programmers have
pushed Uli Drepper hard on the issue of glibc internal encodings.
They want it to support those Creatures from the Pit, Shift JIS and
Big 5, internally. The only way to blunt that is to provide external
_standard_ conversions for every known encoding.
David> As a final note - why does this exist? Linux has a locale
David> standard, in the same way that Perl has a standard
Aka, "why I use Python". :-)
David> - it's called glibc.
Uli Drepper doesn't feel that way, at least not when speaking to
Li18nux-affiliated groups in Japan. "If you can specify it, I can
implement it." It's true he often participates in specification, and
it's true he brooks no interference in his implementation decisions.
But that's not the same thing as saying "the implementation is the
standard."
David> If you feel compelled to write a formal standard, you have
David> to write one that defines what the standard implementation
David> does.
Note what taking that to extremes implies: forget POSIX, which
doesn't describe any real OS. glibc should conform to the undeniable
market leader: the Win32 API. Hey, looks like those IBM code pages
snuck in, again! :-)
While that's mostly a joke, there's something important here. And
that is that if we stick consistently to the "specify, then implement"
approach, we end up with something workable not so far from where we
actually are. But we can't stick consistently with the "make the spec
conform to the `(industry) standard' implementation" without ending up
with something insane way out in right field.
I'm not recommending knuckling under to Emerson's hobgoblin, but I
hope Debian will lean toward specifying desiderata (== standards)
independently of current implementations, rather than falling into the
trap of making the standards overly dependent on the implementations.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Don't ask how you can "do" free software business;
ask what your business can "do for" free software.
Reply to: