Created attachment 47527 [details]
source code 

code uses iso-639.xml and iso-3166.xml which is released under LGPL

Created attachment 47528 [details]
docs and screenshots

Several points:

1. I'm not sure if we want to introduce new API for l10n stuff
2. If we do, we want it much deeper in the stack (i.e. glib, freedesktop,...)
3. If we don't, I'd prefer to try to make generic locale stuff adjustable (I
know how to do that for GNU systems, since you just need to set I18NPATH and
LOCPATH appropriately, and you can generate new locales there)
4. Is 3. possible on other systems as well (eg. Solaris, FreeBSD, *BSD, ...)?

3. would still give us only part of the data that may be interesting to
localisers (i.e. current proposal in this bug involves a couple more date and
time formats than is possible with POSIX "cultural conventions"), so we might
still want to consider creating new APIs, but considering 2. as well

Do we want to do this level of locale setting via a desktop capplet, or might we
want some service that allows access to this on a per-application level instead?  

e.g. some menu item(s) or dialog for doing this that integrates readily into
GTK+ apps.

I don't know whether the multi-locale desktop is a corner case or not, for i18n
users.  It seems not to be a corner case for developers...

in reply to #3:
the api makes life easier for everyone. The capplet calls the set_ methods , and
apps which need locale data call the get_ methods, thus ensuring consistency
across apps. If user hasn't configured the data then the api falls back to icu.
To me icu has  alot of advantages over glib and represents the way forward in
terms of data quality (uses Unicode's CLDR) and range of data available (such as
genetive month names in slavic languages). (see
http://icu.sourceforge.net/userguide/posix.html). 
The api and capplet can be expanded to add extra customised date and time
formats if required (although windows, Mac and KDE all get by with just 2 or 3
of each)

in reply to #4 
this is an interesting proposal. personally I favour the capplet as it
encourages consistency across apps nad I wonder do we need this level of
configurability ? I would assume that the multi-locale desktop is a corner case.
The capplet configures the data on a per locale basis.

Peter, when I'm talking about glib, I'm talking about 
  http://cvs.gnome.org/viewcvs/glib/
and not standard C library (glib is part of Gnome, and provides GObject system
and other misc stuff).  Sorry for the confusion this may have caused, since you
seem to think that I was referring to GNU libc.

All Gtk+ and Gnome apps depend on "glib", since Gtk+ depends on it, whereas
almost none of them require Gnome Control Center, and that's why I wouldn't like
to have this API in g-c-c: we wouldn't be able to make standard Gtk+ widgets use
this API if it was in g-c-c.

My other opinion is that we should also separate out "get-configuration" API
from the one for setting it.  Applications will probably just want to use some a
call similar to the following (I just made this up--I didn't use your enums or
whatever):
  g_l10n_string_for_datetime(DT_LONGFMT | DT_DATE | DT_TIME | DT_GENITIVE,
current_time);

It's far easier to make one function a standard and stable API which would be
supported by all Gtk+ applications, then a bunch of functions we're not yet sure
are sufficient for what we may need in the future (like, I don't see the
genitive support in the API at all).

Though, I'm not sure how can we have these settings in GConf and API in glib,
since glib can't depend on GConf, but this is solvable without too much work
(for example, export values from GConf to some file glib will read for this).

As for what else using this API brings us, you mention genitive support for
Slavic languages: I can't find that in either ICU nor in this API (and I'd
consider that a very useful addition, since we'd finally be able to get correct
quotations in e-mail software without breaking other date displays which require
nominative).

And now that I think of this, should we perhaps add a completely separate l10n
library to our desktop stack, where we can experiment with the API, and ask all
desktop apps to use us?  Basically, separating out your
user-selectable-locale-support-api.c into a separate library.

Having a separate locale library, that exposes from CLDR and allows userlevel
customizations is the way to go IMHO.

Agreed.  Come to think of it, that's where we should probably move language and
country names translation handling code from Epiphany as well (since Epiphany
seems to have gone farthest with it :).  

But, do we have a volunteer? Peter, what do you think about that?

Perfect.  Roozbeh is interested, and should have /some/ time for it.  I'm also
interested (and going to talk about this at DDC next month), but don't have much
time before fall.  If Peter is in, we should have enough knowledge on the CLDR
side.  We can shift to a mailing list and start trying to design something.

I haven't look at the code level yet. Here is my first-sight comments on the 
screenshot and docs.

It lacks a flexible calendar system, and I don't think it should be implemented 
via gnu libc. KDE has provided KCalendarSystem, which allows users to select 
calendar systems other than Gregorian. But unfortunately, Klocale does not allow 
users to select mutiple calendar system with priority at the same time, which is 
obsoletely the wrong solution.

Maybe it is off topic here, but the screenshot looks exactly the same as 
klocale.

A few points:

1. Funda, yes, glibc's Ulrich Drepper has explicitly mentioned that he doesn't
want other calendar systems in glibc and they belong in somewhere else. I also
agree with your point that some users need multiple calendar systems. We need
three in Iran and Afghanistan.

2. I also with to confirm Behdad's point and mention that I also have some time
put aside for this. In GUADEC 6, I also spoke to a few guys about an i18n-l10n
library, including Federico, who is considered a wonderful API designer. We have
their general support, if we clearly explain why this is important and what is
it this provides that is different from what we already get through glibc etc.

3. I really believe Danilo's idea is the way to go here. Peter?

Good to see there's lots of interest in this. 
so it seems we're agreed we need a separate library. 
I also agree with Danilo's point about geenric function names and take
Funda's point about the calendaring system. 
What's there at the moment is just a prototype.

Two other challenges we face are :
1. using gconf means the library is restricted to windowing apps.
so "ls -l" "date" etc will be unaffected. But does the average user ever use CLI ?
2. In order for configurability to work we need to convince app owners to cut
down on the number of date and time formats they want. There are approx 20
different date formats and 6 or 7 different time formats in the evolution, clock
and nautilus po files. Although, I'm not sure if they're all used and maybe we
could use some combinatorics or other tricks to address this.

The question now is what advantages does a new CLDR api give us over ICU. 
I'm open to be convinced either way and am happy to help impelement whatever
design is agreed as long as we don't end up "re-inventing the wheel"

Re nominative and genitive month names in ICU :
I would assume udat_getSymbols () returns nominative and udat_format () uses
genitive names if appropriate. I know for sure ICU contains both forms, I
checked Russian.
Also, ICU has language and Country name data and supports different calendars

No matter how the the lib will be built, just keep it in mind that calendar 
system should be independent from anything else. And, users might want to enable 
multiple calendar systems with priorities at the same time.

For example the Chinese Fortune Calendar, which is the most commonly used 
calendar system in China besides Gregorian calendar, because some traditional 
holidays such as Spring Festival are calculated according to Fortune Calendar. 
Of course, we would like to show the date in Fortune Calendar in clock applet, 
at least in tooltip. But for the other places, such as the modified date of 
files, or the sent date of a message, Fortune Calendar is of no use. I think the 
situation will likely be the same for other calendar systems.

The problem maybe not related to the implementation of certain calendar system, 
but the representation to the desktop, which is the task of glib, I think.

I think as a first step, we need an CLDR wrapper.  I prefer to have a lib that
simply exports CLDR, and see a full-featured locale library built on top of
that, if need be.  The advantage with this approach is that we are decoupling
two tasks:  Efficiently querying the CLDR data, and exposing a convenient interface.

About ICU, the problem is that we cannot and do not want/like to use ICU.  We
need a light-weight shared library exporting C interface.

I think calendars can sit into yet another library that the locale library is
built on top (replacing libical prolly).  So, to start with, we need the CLDR
wrapper.  It can happily go on fd.o.  Roozbeh, can you start that?  We should
use Glib of course.

After we have a mailing list set up, we can discuss about API.  We should get an
overview of the CLDR raw data, ICU API, and KDE API first, before we can get our
hands dirty.

My 2 Canadian cents

I think we should start by writing a requirements/functional spec of what we
want the api to do. We can start with user-select-locale-support.h and go from
there. 
Behdad : are you going to set up a mailing list ?
I'd also like to know exactly what the problem with ICU is ? is it a licensing
issue, or something else ? I'm new to opensource so probably I'm missing
something. In any case I still have an open mind.

Mailing list, I prefer it if Roozbeh follow up, but I will start requesting and
will CC him.

About ICU, there are multiple problems:

- ICU is written in C++, with a C++ interface.  GNOME is written in C, which
makes it really really hard to use ICU.

- ICU is pretty fat.  It surely contains lots of good stuff, but it contains
lots of stuff that we already have too.  Like text renderers, etc.

- ICU never shipped as a shared library on Unix systems.  I do not know the
exact reason, but it simply didn't work out.

Becuase of these reasons and other reasons that I can recall right now, ICU is
perfectly fine to be used in a project so big as OpenOffice.org, but compared to
the relatively tiny GNOME, ICU is just no choice.

That's just my view though.

Regarding comment #14 and wrapping CLDR: that's ok, but I'd rather if we go and
define things only as we need them, i.e. build the API from the ground up.  I.e.
we know we need a date and time formatting function, so lets add that to the
API.  Next, we want to allow setting date and time formats there, so lets add
configuration API as well.  We need number and currency formatting as well, so
that should go in too.

Just lets not restrict our minds to what CLDR offers, even though it may offer
more than we need at the moment :)

I agree that using ICU might not be the best option, since it really introduces
too many things we don't really need.

I ageee with Danilo : we need to define what we need the api to do as a first
step. The examples you mention are already in the api (I know it may need to be
tweaked and is not complete).
Re ICU : it also has a C API, and already ships on solaris. If size is an issue
we could probably just build the parts we need, I know that can be done easily
for icu4j.

For what it's worth, if iso-codes xml files are to be used, please depend on
them using pkg-config, and don't include them in the control-center. Totem and
epiphany are already users of that library.

Bastien, we've already concluded that we want to move everything into a separate
i18n library.  I actually think we should also move that code from both Totem
and Epiphany to such a i18n library, and have them use it instead.  This should
also help all future potential users of iso-codes, since they wouldn't
copy-paste code, but would rather just use the library which is already available.

Of course, I think your experience with what might be needed in the API is most
welcome, as is those of epi maintainers.

Roozbeh, what's going on with the list and project?  Any progress there? (I'd
also like to move this bug to "general" product if nobody minds, since
control-center part of the this is only a part of the problem)

Daniel,
go ahead and move the bug to general. We need to get buy in from lots of app
owners etc for this so your suggestion makes sense. There's been no progess in
the last few days (AFAIK). I suggest we try to agree a functional spec as a
starting point. I can start on this tomorrow probably.
Roozbeh : are you going to set up a mailing list ?

I've already asked fd.o sitewranglers for the mailing list, but have not got any
response yet.  I'll ping them again.

About functional spec vs. CLDR wrapper, like I said before, I suggest we go for
a CLDR wrapper library and a separate liblocale library, because that way we
have decoupled the CDLR handling code from the user API that needs design from a
user's point of view.  In other words:  We know that we want the data for the
locales to come from CLDR, so lets wrap CLDR first.  That's my view.  Of course
this doesn't prevent people from desiging the API in parallel.

Sorry for not answering here. I believe Behdad is the best person to do the
mailing list thing.

But I recommend doing it in the gnome level first, instead of thinking
freedesktop.org and then having an adoption problem. It should also be easier
for people like Danilo, as the co-leader of the translation effort and
maintainer of other things, to get a list on lists.gnome.org. Buying app-buyers
in GNOME would also be a lot easier for us if we do it properly in GNOME. We
don't know that many people in the KDE world, for example. Let's see if we can
do it in GNOME and then try to reexport it.

Humm, sounds not bad.  First, fd.o is a bit unresponsive at times (like this),
second, KDE already has a locale system in place, so, yes, let keep it in GNOME
which is easier to test for people, and easier to get people involved.  Danilo,
would you ask for a list?  I don't know the procedure for gnome.org.

Anyone keen on suggesting a name I should ask for? libl10n-list?

The list can be simply locale-list IMO.

Start discussing everything:
  http://mail.gnome.org/mailman/listinfo/locale-list

Anyone wants to be a moderator as well? :)

There is no such capplet anymore... If specific problems exists nowadays in GNOME Settings / gnome-control-center, please file a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/issues/