Re: gettext's glocale

[danilo gnome org (Danilo Šegan)]

Today at 14:33, Roozbeh Pournader wrote:

> 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.

We can actually influence glibc data during runtime using LOCPATH and
I18NPATH (i.e. we can always create new locales, but we'd probably
need to set environment variables beforehand).  Anyway, we'd want to
recommend all applications to use our own API which would give
consistent results (i.e. CLDR as more complete of the two; GNU libc
would only be a fallback).

> 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.

GNU libc locales also have these, it's only that they're all stacked
in a "modifier" place (eg. "currency=euro" would be "@euro", and
Cyrillic script would be "@cyrillic").  It's easy to parse these and
construct an appropriate map, since there are only a few of them.

> 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

It does, but half of GNOME would not be translated because Solaris
gettext is far too much behind GNU gettext (intltool doesn't support
Solaris one because it's unusable—really—and we tried!).

> , 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?

I think we need not worry about Mozilla.  They also have the option of
using Gtk2 (LGPL) and Pango (LGPL) for the UI and rendering stuff, so
I'm not really concerned.  And as you said, Qt is unlikely to start
using it anyway (they need to keep an eye on Windows portability as
well).

Cheers,
Danilo