Bug 619287 - [ALL LANG] Time-Zones are untranslated for All supported languages
[ALL LANG] Time-Zones are untranslated for All supported languages
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: system-config-date (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Nils Philippsen
qe-baseos-daemons
: i18n
: 589172 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-29 03:30 EDT by A S Alam
Modified: 2013-07-02 21:03 EDT (History)
8 users (show)

See Also:
Fixed In Version: system-config-date-1.9.60-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 16:41:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ja_JP Screenshot for TimeZone Screen in Anaconda (118.89 KB, image/png)
2010-07-29 03:38 EDT, A S Alam
no flags Details

  None (edit)
Description A S Alam 2010-07-29 03:30:37 EDT
Description of problem:
During installation, timezone data (ALL City Names) are in English, while those are translated.

Version-Release number of selected component (if applicable):
anaconda-13.21.61

How reproducible:
100%

Steps to Reproduce:
1. start anaconda with any language (tested with Japanese)
2. got Time Zone Selection
3.
  
Actual results:
City Names are untranslated

Expected results:
this should be Localized

Additional info:
Effecting All RH Supported languages, So asking for Blocker
Comment 2 A S Alam 2010-07-29 03:38:43 EDT
Created attachment 435204 [details]
ja_JP Screenshot for TimeZone Screen in Anaconda
Comment 3 David Cantrell 2010-07-29 12:15:09 EDT
We just import zonetab from system-config-date in anaconda.
Comment 4 Nils Philippsen 2010-08-02 09:38:06 EDT
I tried this with the current version of s-c-date, and it works in the standalone app. I suspect the issue is a side-effect of some "magic" anaconda does. Investigating.
Comment 6 Phil Knirsch 2010-08-05 11:05:32 EDT
Nils found the final cause of the problem. The actual problem comes from anaconda having to switch languages during runtime and s-c-d basically not knowing about this.

He has a fix ready for system-config-date which he verified in a test environment which resolves this.

And as this is highly visible for any installations in other languages than English i'd definitely consider this a blocker bug.

Thanks & regards, Phil
Comment 7 Nils Philippsen 2010-08-05 12:00:41 EDT
This is the fix I pushed into the upstream repo:

commit ae508989c4318e0729704c6a35c904d6d1c3007e
Author: Nils Philippsen <nils@redhat.com>
Date:   Thu Aug 5 17:19:40 2010 +0200

    make time zones translations work in anaconda
    
    Unfortunately, anaconda changes languages during runtime, long after
    scdate.core.util loaded its message catalogs. Wrap _, ugettext so that
    it checks for language changes and installs a new GNUTranslations object
    for the new language in that case.
Comment 8 Nils Philippsen 2010-08-06 06:46:00 EDT
And another one which invalidates pre-created (potentially partial) time zone translations upon language change:

commit be740e320826a28db12d033e1594bb5bda3d5bf5
Author: Nils Philippsen <nils@redhat.com>
Date:   Fri Aug 6 12:28:48 2010 +0200

    recreate TZ translations after each language change
    
    ZoneTabEntry objects generate (potentially partial) translations of
    their time zone names upon creation. In order to be able to change the
    language after they have been created, these translations must be
    recreated. This is mainly needed for scdate.core.zonetab to be used in
    anaconda which allows language changes during runtime.

This is necessary because the time zone entry objects are created when the time zone window is shown for the first time. I.e. if the user steps back and changes the language again, it won't have any effect without this change.
Comment 12 Ankit Patel 2010-08-09 07:19:24 EDT
FIXED.

TESTED and VERIFIED with system-config-date-1.9.60-1.el6.

Thanks!
Ankit
Comment 13 A S Alam 2010-08-15 15:07:32 EDT
status - FAIL
tested package: system-config-date-1.9.60-1.el6.noarch

detail:
---
each locale give following warning:
---
Running zh_TW.UTF-8
/usr/lib/python2.6/site-packages/scdate/core/zonetab.py:218: RuntimeWarning: Untranslated time zone: Pacific/Chuuk
  entry = ZoneTabEntry (code, lat, long, tz, comments)
/usr/lib/python2.6/site-packages/scdate/core/zonetab.py:218: RuntimeWarning: Untranslated time zone: Pacific/Pohnpei
  entry = ZoneTabEntry (code, lat, long, tz, comments)
/usr/lib/python2.6/site-packages/scdate/core/zonetab.py:218: RuntimeWarning: Untranslated time zone: America/Bahia Banderas
  entry = ZoneTabEntry (code, lat, long, tz, comments)
----

Closing Bug #589172 as duplicate for this
Comment 14 A S Alam 2010-08-15 15:09:26 EDT
*** Bug 589172 has been marked as a duplicate of this bug. ***
Comment 15 Nils Philippsen 2010-08-16 08:23:50 EDT
(In reply to comment #13)
> status - FAIL
> tested package: system-config-date-1.9.60-1.el6.noarch
> 
> detail:
> ---
> each locale give following warning:
> ---
> Running zh_TW.UTF-8
> /usr/lib/python2.6/site-packages/scdate/core/zonetab.py:218: RuntimeWarning:
> Untranslated time zone: Pacific/Chuuk
>   entry = ZoneTabEntry (code, lat, long, tz, comments)
> /usr/lib/python2.6/site-packages/scdate/core/zonetab.py:218: RuntimeWarning:
> Untranslated time zone: Pacific/Pohnpei
>   entry = ZoneTabEntry (code, lat, long, tz, comments)
> /usr/lib/python2.6/site-packages/scdate/core/zonetab.py:218: RuntimeWarning:
> Untranslated time zone: America/Bahia Banderas
>   entry = ZoneTabEntry (code, lat, long, tz, comments)
> ----

This is because there has been an update to tzdata which introduced new time zone names and descriptions (Petr, yet another instance which shows why we should get tzdata-i18n going ;-).

I've pulled in the strings so they can be translated upstream, but as it is right now, these new time zones should be displayed correctly: system-config-date uses partial translations (e.g. for the continent) where complete translations are not available. The actual location part is a proper name, which only rarely gets translated for well known locations (e.g. "Copenhagen - København - Kopenhagen", "Munich - München", "New Delhi - Neu Delhi"), I guess it's safe to assume that these places don't need translations for their own names. Changing status to MODIFIED. Feel free to open a new bug for 6.1, but for that we should wait with translating time zones until we know there won't be new strings coming in from tzdata.
Comment 16 Petr Machata 2010-08-16 10:14:54 EDT
> Petr, yet another instance which shows why we should get tzdata-i18n going ;-)

Oh I think that's established quite well :)
Comment 17 Denise Dumas 2010-08-17 17:51:12 EDT
Should this actually move back to on-qa?
Comment 18 Nils Philippsen 2010-08-18 08:34:00 EDT
My impression was that QE changes status from MODIFIED to ON_QA if they pick it up again.
Comment 20 A S Alam 2010-08-19 09:03:40 EDT
Bug is Verified with comment #13 and Comment #15

tested Package: system-config-date-1.9.60-1.el6
Comment 21 releng-rhel@redhat.com 2010-11-10 16:41:05 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.