Re: gettext's glocale

[Roozbeh Pournader <roozbeh farsiweb info>]

Hi Bruno,

Thanks for letting us know, and also for the offer. The functionality
looks very promising.

I came to a few questions that we need to answer before deciding if we
want to merge or not:

1) What should we do with data conflicts? Let's says an application
developer wants a simple date displayed in, say, French, and CLDR and
glibc have different answers for the question?

Should we have a unified API and only give him CLDR data? In this case,
he will get different results by doing a strftime and a gl_strftime for
the same locale. It's not desirable.

Should we have a unified API and only give him glibc data? In this case,
he will probably get the worst data of the two, since glibc is more
limited and may be more out of date.

Or should we have two APIs for giving him whichever he wants? In this
case, how do we suppose he can find about which API to use for some need
he has?

2) How should we map the CLDR locale system to the glibc locale system
and vice versa?

While glibc has language, territory, encoding, and a variant, in CLDR
there are language, script, territory, variant, and some options as key-
value pairs.

We will need to answer the question anyway, but independently, we can
answer it our way. If we work together, we should do it much more
carefully.

3) How do we make it more independent of GNU?

Most of the user-level applications have tried to be portable. GNOME
runs on Solaris which has its own gettext, Qt and Mozilla don't use LGPL
libraries where they can be avoided at any cost, etc.

While we understand that they may be overdoing it, I believe we prefer
wider adoption to having a nice library that's not used by the
applications for various licensing-related reasons and hence doesn't
benefit the final user after all the effort. (We are planning to move
this out of GNOME after we experimented with things a little.) What do
you think we should do about this?

Also, I have another question below:

On Wed, 2005-08-10 at 19:22 +0200, Bruno Haible wrote:
> It is separate from glibc, because the glibc maintainer didn't acknowledge
> that having a 'locale_t' data type usable on its own was important. He
> argues that tying it to the current thread is better.

Do you know his reasons? I'd love to know them.

roozbeh