Comment 23 for bug 1160441

Thanks, Colin.

Subscribing Mathieu Trudel-Lapierre and Martin Pitt.

Let me try to summarise the discussions the past few months on how to deal with bug 1072019, of which this bug is in fact a duplicate. Whatever we finally agree on, this is not an installer only matter.

I started to write the indicator-datetime (i-d) MP.
https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214
Charles Kerr and Martin thought it would be better to do it in GLib, so I went on with https://bugzilla.gnome.org/687945
Matthias guided me to make the GLib patch uploadable, and then he rejected it. :(

So we were back at the i-d level. Martin approved the idea of doing it there, and Mathieu seems to be ready to merge my MP as soon as he has convinced himself that it works properly. ;-) Nobody thinks it's a perfect solution, but it does address the issue at hand.

The function in the MP is a standalone wrapper around g_date_time_format(), and could well be used by other date/time apps if needed. Well, to make it generally applicable, code for dealing with the %c conversion specification would need to be added. (i-d does not currently use %c.) OTOH, personally I think that this is mostly a calendar issue. I have never seen anybody complain in any other context about names of days and months not being properly translated due to the LC_TIME spec.

Let's look at the other path, i.e. setting LC_TIME in accordance with the selected language. In language-selector (and "Region & Language" in g-c-c) the users explicitly select formats in accordance with the conventions in a particular country/region. Both UIs show examples of what a particular setting results in. Should we remove the examples of how dates and times are displayed? Wouldn't that be a really weird step to take? After all, I suppose we agree that distinguishing between language and regional formats is a reasonable approach, and date/time formats is a typical area that differs between countries.

Unfortunately the standard makes it difficult to do the right thing with respect to LC_TIME. But shouldn't we take pains to meet legitimate user expectations even if the available tools aren't ideal? To me it's obvious that we should. And given the reaction to the GLib bug, doing it at the app level appears to be what's possible for the foreseeable future.