Re: Extent of localisation customisation

[Danilo Segan <danilo gnome org>]

On Tuesday at 23:19, Alan Cox wrote:

> On Maw, 2004-06-08 at 16:25, Danilo Segan wrote:
>> Whatever GNOME does wouldn't be done on system-level, so there would
>> be a lot of inconsistent messages.  So, some programs might still
>> produce locale-based date-format if it's using strftime instead of
>> "g_strftime".
>
> If they produce different results then fix g_strftime so it isnt buggy.

I never said that -- I'm not even sure g_strftime exists.  I was
referring to using things like "%c" or "%x" (which depend on current
locale).  So, if we go the route of making changes in Gnome-only
date-n-time libraries, we'd get inconsistent output in many programs
(because some would use system functions).

Therefore, I consider the only "realistic" short-term goal to be the
following:

>> Realistic goal seems to be to aim for a single platform: i.e. we
>> could base ourselves on all the locales provided by GNU libc.  If
>> there's a strong need for a variant locale, then we create a new one
>> and try to add it to GNU libc (it's trivial to make such simple
>> changes, but it's not trivial to add new locales to GNU libc, and we
>> don't want to add thousands there, just ocassional, really needed
>> ones).
>
> You get combinatorial explosions. Providing you stop talking about
> locales and start talking [IYNativeLanguageH] then users seem to have no
> problem with the idea of date order, number format and so on as further
> optional choices. Its something non programmers deal with all the time.
> Most people know about the funny US date format.

Yeah, but I'm talking only about most common stuff: there's
no need to make  "number-of-languages * number-of-options *
number-of-variants-of-the-option" because not all of them are likely
to be used often.

Just like there's no combinatorial explosion with using "ll_CC" code:
we don't have number-of-languages * number-of-countries locales:
these codes are assigned per need.

We can even go the route of "generic" locales which provide these
variants, and which we set using LC_* environment variables (I prefer
this solution, but it would still be hard to get these "generic"
locales into GNU libc).   Imagine locales "i18n date-blah",
"i18n date-pooh", ...

I'm not arguing against user expectations here -- I'm talking about
pragmatic solutions.  Unless, of course, we want to drop POSIX locale
style, and switch to something more useful (ICU locale database
perhaps?), which would allow things like these (i.e. if LC_CURRENCY
was actually able to accept values like "#.###,## $", we'd have no
problem).

But that is still not a short-term solution, since it involves a lot
of changes in many places.

Perhaps I'm missing something?

Cheers,
Danilo