Calendar is still in English despite French is selected as the Language during the installation

Bug #1160441 reported by Para Siva on 2013-03-26
24
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Indicator Date and Time
In Progress
Undecided
Gunnar Hjalmarsson
evolution (Ubuntu)
Medium
Gunnar Hjalmarsson
Raring
Medium
Gunnar Hjalmarsson
evolution-data-server (Ubuntu)
Medium
Gunnar Hjalmarsson
Raring
Medium
Gunnar Hjalmarsson
localechooser (Ubuntu)
Medium
Unassigned
Raring
Medium
Colin Watson
ubiquity (Ubuntu)
Medium
Unassigned
Raring
Medium
Unassigned

Bug Description

When London is selected as the location and language is selected as French, the calendar entries are shown in English. The calendar shows correct London date and time but presents them in English. One would expect that the calendar entries would be shown in French as it used to be the case.

This occurs in installations with and without network, with and without live session and on both amd64 and i386 of 20130326 images. When Paris is selected as the location, the calendar entries are shown in French.

Incomplete language support dialog pops up (for networkless installations) after the reboot but updating the language does not solve the issue.

Steps to reproduce:

1. Boot the usb with todays image (20130326)
2. Select French language for installation
3. Continue with default settings except the location setting, which should be set to London
4. Finish the installation and reboot.
5. Check the calendar entries

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: ubiquity 2.13.17
ProcVersionSignature: Ubuntu 3.8.0-14.24-generic 3.8.4
Uname: Linux 3.8.0-14-generic i686
ApportVersion: 2.9.2-0ubuntu4
Architecture: i386
CasperVersion: 1.330
Date: Tue Mar 26 15:20:47 2013
LiveMediaBuild: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130326)
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :
description: updated
Para Siva (psivaa) wrote :
Para Siva (psivaa) wrote :
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1160441

tags: added: iso-testing
Para Siva (psivaa) wrote :

The regression appears to be in ubiquity (2.13.12) since up until ubiquity (2.13.11) this issue was not present. The calendar entries were presented in the correct language until this older version.

Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
Brian Murray (brian-murray) wrote :

I tested this with an image from 20130409 and while "Time & Date Settings" entry is translated the days of the week and month are not.

Changed in ubiquity (Ubuntu Raring):
status: New → Triaged
Brian Murray (brian-murray) wrote :

After changing the Regional Formats section of Language Support to francais (France) from English (United States) the days of the week and the month were properly translated so perhaps ubiquity is not setting that properly.

Colin Watson (cjwatson) wrote :

Please attach /etc/default/locale; this could be related to bug 1158750. (Or it's possible that the fix for bug 1158750 could have been responsible for the improved behaviour Brian reported, but that we still need to fix something else.)

Brian Murray (brian-murray) wrote :

Using media from Ubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130410)

/etc/default/locale contains

LANG="fr_FR.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"

Brian Murray (brian-murray) wrote :

I wonder if bug 1072019 is related to this.

Colin Watson (cjwatson) wrote :

I don't think we can win either way, really, since LC_TIME is a conflated category: it includes both the general way that time is displayed (date ordering, 12-hour vs. 24-hour clock, etc.) and the translations of days and months. If your language and location don't have a complete locale in common then there is no single thing we can do that will keep everyone happy. However, it does seem like the lesser of two evils to get the day and month translations right, so I think I'll switch to that.

Changed in localechooser (Ubuntu Raring):
status: New → Triaged
importance: Undecided → Medium
Colin Watson (cjwatson) on 2013-04-18
Changed in localechooser (Ubuntu Raring):
status: Triaged → Fix Committed
assignee: nobody → Colin Watson (cjwatson)
Changed in ubiquity (Ubuntu Raring):
assignee: nobody → Colin Watson (cjwatson)
Colin Watson (cjwatson) on 2013-04-18
Changed in ubiquity (Ubuntu Raring):
status: Triaged → Fix Committed
Gunnar Hjalmarsson (gunnarhj) wrote :

@Colin: It's fully possible to make everyone happy, if you like to. ;-)

I have struggled with this issue during the Raring cycle. I proposed a change to g_date_time_format() - https://bugzilla.gnome.org/687945 - but was was turned down by Matthias Clasen (for reasons I'll never understand). Now there is a pending MP against indicator-datetime instead: https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214

No change to glib can possibly solve the fact that the two kinds of
locale data - (1) language-independent details such as 12/24-hour clock,
which day starts the week, and so on, and (2) language-dependent
translations of weekdays and months - are fundamentally conflated into a
single category in POSIX and in glibc's locale database. Changing
either glib or indicator-datetime is addressing the problem at the wrong
layer, which you can tell by the fact that it doesn't affect anything
using other time-related functions.

Changing indicator-datetime wouldn't be dreadful, perhaps. But it
really doesn't have any bearing on what ubiquity does here, because
ubiquity should be configuring the system as correctly as possible,
supporting more than just the Unity indicators stack.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package localechooser - 2.49ubuntu3

---------------
localechooser (2.49ubuntu3) raring; urgency=low

  * Set LC_TIME to reflect the language rather than the location, as the
    lesser of two evils since it includes translations of day and month
    names (LP: #1160441).
 -- Colin Watson <email address hidden> Thu, 18 Apr 2013 12:30:53 +0100

Changed in localechooser (Ubuntu Raring):
status: Fix Committed → Fix Released
Gunnar Hjalmarsson (gunnarhj) wrote :

Suddenly I realised what you did, Colin, and I must say that I disagree. The very reason why the LC_TIME locale category exists is reasonably the fact that date and time formats vary between countries/regions. The calendar issue with days and months doesn't change that.

At least a change like this should not happen without discussion right before a release IMNSHO. Since language-selector for several years sets LC_TIME in accordance with the selected region, we indeed have an inconsistency now.

I ask you to please revert this change in Raring. Then we can talk more about what to do going forward.

Colin Watson (cjwatson) wrote :

After a lengthy debate on IRC:

localechooser (2.49ubuntu4) raring; urgency=low

  * Revert previous change since at least language-selector also needs to be
    brought into sync, and it's too late for 13.04.

 -- Colin Watson <email address hidden> Thu, 18 Apr 2013 17:31:57 +0100

Changed in localechooser (Ubuntu Raring):
status: Fix Released → Won't Fix
Changed in localechooser (Ubuntu):
status: Fix Released → Triaged
Changed in ubiquity (Ubuntu Raring):
status: Fix Committed → Won't Fix
Changed in ubiquity (Ubuntu):
status: Fix Committed → Triaged
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.14.5

---------------
ubiquity (2.14.5) raring; urgency=low

  * Revert LC_TIME change from previous upload since at least
    language-selector also needs to be brought into sync, and it's too late
    for 13.04.
  * Automatic update of included source packages: localechooser 2.49ubuntu4.

ubiquity (2.14.4) raring; urgency=low

  * Set LC_TIME to reflect the language rather than the location, as the
    lesser of two evils since it includes translations of day and month
    names (LP: #1160441).
  * Allow preseeding "ubiquity ubiquity/automatic/timezone boolean true" to
    skip the timezone question (LP: #1097113). This is intended to be part
    of a more general mechanism, but not a week before release.
  * Update translations from Launchpad.
  * Automatic update of included source packages: localechooser 2.49ubuntu3.
 -- Colin Watson <email address hidden> Thu, 18 Apr 2013 18:28:16 +0100

Changed in ubiquity (Ubuntu Raring):
status: Won't Fix → Fix Released
Colin Watson (cjwatson) wrote :

ubiquity (2.14.5) raring; urgency=low

  * Revert LC_TIME change from previous upload since at least
    language-selector also needs to be brought into sync, and it's too late
    for 13.04.
  * Automatic update of included source packages: localechooser 2.49ubuntu4.

 -- Colin Watson <email address hidden> Thu, 18 Apr 2013 18:28:16 +0100

Changed in ubiquity (Ubuntu Raring):
status: Fix Released → Won't Fix
Gunnar Hjalmarsson (gunnarhj) wrote :

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.

Changed in indicator-datetime:
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
status: New → In Progress
Para Siva (psivaa) wrote :

So I installed the version of indicator-datetime in my PPA
(https://launchpad.net/~gunnarhj/+archive/misc) on a French language installation where the calendar entries were still in English. (Added the ppa, updated the system and then installed indicator-datetime) But the calendar entries (months, days) were still in English even after the installation of that PPA.

I also tried installing the ppa from a live session and did the installation but the issue was still present. Thanks

Gunnar Hjalmarsson (gunnarhj) wrote :

Thanks for testing!

Hmm... Are we possibly talking about different calendars? I assumed that you meant the simple calendar that shows up if you click the time/date indicator at the top right of the screen. Do you mean something else, e.g. Evolution?

Gunnar Hjalmarsson (gunnarhj) wrote :

Even if we don't know for sure yet which calendar psivaa refers to, the issue in the bug description is present in the Evolution calendar. I have prepared a couple of Evolution proposals that fix it. Please feel free to test the proposals by installing the evolution and evolution-data-server packages from my PPA at https://launchpad.net/~gunnarhj/+archive/misc

Since this bug report is not about indicator-datetime, I deleted the Indicator Date and Time task.

tags: added: patch
no longer affects: indicator-datetime
Changed in evolution (Ubuntu Raring):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → In Progress
Changed in evolution-data-server (Ubuntu Raring):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → In Progress
Para Siva (psivaa) wrote :

@gunnarhj: Yes, The calendar that I refer in this bug report is the one that shows up when I click the time indicator at the top right corner of the screen. Please see attachment 7 (Screen_1). Thanks

Gunnar Hjalmarsson (gunnarhj) wrote :

@psivaa: So you meant indicator-datetime, after all. That's what I first thought. ;-)

It's strange that the indicator-datetime version in my PPA doesn't fix the issue for you. It works fine for me, and the reporter of bug 1072019 just confirmed that it works for him.

Actually, Screen_1.jpg does not confirm the issue you say you have. Even if some folders in your $HOME have French names, the current locale might have been changed since your user was created. What does the command

  locale

in a terminal window output?

Changed in indicator-datetime:
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
status: New → In Progress
Para Siva (psivaa) wrote :

locale returns the following

ubuntu@ubuntu-Inspiron-N4010:~$ locale
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC=en_GB.UTF-8
LC_TIME=en_GB.UTF-8
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY=en_GB.UTF-8
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER=en_GB.UTF-8
LC_NAME=en_GB.UTF-8
LC_ADDRESS=en_GB.UTF-8
LC_TELEPHONE=en_GB.UTF-8
LC_MEASUREMENT=en_GB.UTF-8
LC_IDENTIFICATION=en_GB.UTF-8
LC_ALL=

The issue that I reported in this bug is that even though the locale is French, the calendar entries are in English ( the location that I selected during the installation was London). Screen_1.jpg shows the exact thing that I think as a regression. We used to have the calendar entries localised in the language selected up-until the images that contained ubiquity (2.13.11) or earlier. It may not be a regression in ubiquity but the behaviour changed after 2.13.12 onwards.

Gunnar Hjalmarsson (gunnarhj) wrote :

Well, I'd call it a perceived regression. ;-) What happened is that the installer started to assume/guess that since you selected London as the time zone location, you want that things like numbers, currency, date, and time are displayed using the format conventions in Great Britain.[1] Unfortunately some applications, including indicator-datetime, display the names of weekdays and months in the corresponding language, even if the language you explicitly selected is something else.

But the indicator-datetime version in my PPA should fix that. Are you really sure that you installed that package successfully? A simple way to find out is to run this command in a terminal window:

  dpkg -l | grep indicator-datetime

The version should be "12.10.3daily13.03.26-0ubuntu1+daysMonths".

[1] Please note that you can change the language and regional formats settings via "System Settings -> Language Support".

Para Siva (psivaa) wrote :

I can confirm again that the ppa does not fix the issue that I reported. i.e. even after installing the ppa and rebooting, the calendar entries were still in English.

Here follows the package installed

ubuntu@ubuntu-Inspiron-N4010:~$ dpkg -l | grep indicator-datetime
ii indicator-datetime 12.10.3daily13.03.26-0ubuntu1+daysMonths amd64 Simple clock

And as Brian confirmed in comment #11 that changing the Regional Formats section of Language Support to francais (France) solved the issue ( that is even before installing the above ppa ) :)

Gunnar Hjalmarsson (gunnarhj) wrote :

It's fine that you are able to change the appearance to your liking. :) By selecting France for the regional formats, you get a French locale all through, i.e. what the installer used to deliver before the change. Possibly, in your case, that's what you want, also with respect to date/time formats, currency, numbers, etc.

I for one can't help wondering why the indicator-datetime version in my PPA didn't make a difference for you. :(

Thanks!

Jamie Strandboge (jdstrand) wrote :

Unsbuscribing ubuntu-sponsors for now as there doesn't seem to be anything to sponsor. If this is in error, please resubscribe stating what needs to happen to resolve this issue. Thanks!

Rolf Leggewie (r0lf) wrote :

raring has seen the end of its life and is no longer receiving any updates. Marking the raring task for this ticket as "Won't Fix".

Changed in evolution (Ubuntu Raring):
status: In Progress → Won't Fix
Changed in evolution-data-server (Ubuntu Raring):
status: In Progress → Won't Fix
Colin Watson (cjwatson) on 2014-12-18
Changed in localechooser (Ubuntu):
assignee: Colin Watson (cjwatson) → nobody
Changed in ubiquity (Ubuntu Raring):
assignee: Colin Watson (cjwatson) → nobody
Changed in ubiquity (Ubuntu):
assignee: Colin Watson (cjwatson) → nobody
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers