Bug 131528 - Localization does not contain zones name
Localization does not contain zones name
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-date (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nils Philippsen
: i18n, Translation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-09-01 17:34 EDT by Andrew Martynov
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version: system-config-date-1.8.3-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-28 06:00:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
redhat-config-date/po/Makefile (2.84 KB, text/plain)
2004-09-22 10:33 EDT, Andrew Martynov
no flags Details
Screenshot of the system config date window. (80.51 KB, image/jpeg)
2006-04-28 06:05 EDT, Satyabrata Maitra
no flags Details

  None (edit)
Description Andrew Martynov 2004-09-01 17:34:21 EDT
Description of problem:
After running system-config-date in ru_RU locale
we did not see localized timezones names as in Anaconda.

Anaconda translation .pot file has lines 
#. generated from zone.tab
msgid "Moscow+00 - west Russia"

So after running utility user can see localized part in right and 
left panes on second page (tab).

Version-Release number of selected component (if applicable):
1.7.4 - current CVS version.

How reproducible:
Always

Steps to Reproduce:
1. export LANG=ru_RU.UTF-8
2. system-config-date
3. switch to second tab
4. look at entries like "Moscow+00 - west Russia"
  
Actual results:
Untranslated items

Expected results:
Translated text as in time zones dialog during installation in 
Anaconda.

Additional info:

I suppose that it is not too hard move some msgid lines from anaconda 
to system-config-date.pot file or in timezones.pot.

Thank you,
Andrew Martynov
Maintainer of Fedora Project translation to Russian
Comment 1 Leon Ho 2004-09-15 21:57:38 EDT
Nils, looking at the system-config-date/po/timezones/Makefile, look
like the pot is generated thru /usr/share/zoneinfo directory. The
comments that the reporter mentioned is in
/usr/share/zoneinfo/zone.tab. We can probably change to grab string
from that zone.tab stead of directories and file in there, but I am
not sure how much changes will it be for the pot and definitely will
affect the string freeze. Assigning to revelant component and added
i18n keyword. 
Comment 2 Andrew Martynov 2004-09-16 01:25:47 EDT
Most of strings is already translated in Anaconda package.

I see three quick resolutions:
- add new strings to .pot file and ask translators copy 'msgstr' from
anaconda package translations
- insert into Makefile stub to make 'msgmerge' this additional strings
from anaconda
- insert into Makefile stub to include all anaconda translations into
produced .mo file. Yes, it will swell and it is not optimal decision.
Comment 3 Leon Ho 2004-09-16 09:39:32 EDT
Manually adding strings into pot may not be a good idea. Proabably 
the right way to do it is something similar what you said on your 2nd 
point - but grabs strings in zone.tab to generate msgids in Makefile. 
And then probably you guys can use msgmerge to merge some of the 
translation from anaconda.po to there to save some translation work. 
However the strings in pot will be changed (this falls into grey area 
of 'string change' deadline as it is already past)and some 
translators may not able to complete this module to 100% on the 
deadline. Well this is a maintainer decision. We will support in 
either ways.
Comment 4 Andrew Martynov 2004-09-16 09:53:36 EDT
Even if .pot file will be modified after 'string change' situation 
will not be worse, because user interface is not translated.

It is good idea to announce this to fedora-trans@redhat.com
and Translator maintainers will done their work as soon as possible.

We has one more week to complete translations.
Comment 5 Nils Philippsen 2004-09-16 10:36:24 EDT
I personally like this one:

- insert into Makefile stub to make 'msgmerge' this additional strings
from anaconda

would you help me on that one? -- I'm not that up-to-par with the i18n
infrastructure (yet) and I don't want to screw up translations completely.
Comment 6 Andrew Martynov 2004-09-16 10:42:47 EDT
I agree, it is good decision. 

I will test this and post my suggestion tomorow.
Comment 7 Andrew Martynov 2004-09-22 10:30:12 EDT
Corrected Makefile is attached.

I propose to use installed anaconda package and coresponding .mo files
to generage zone.tab translation during producing .mo files for
redhat-config-date.

It is required to modify .spec file and add 'BuildRequires: anaconda'.

Only .mo target is modified
Comment 8 Andrew Martynov 2004-09-22 10:33:23 EDT
Created attachment 104127 [details]
redhat-config-date/po/Makefile

Corrected Makefile to generate missing zone.tab translations from anaconda
package. It is required to show right side of timezones in location selection
listbox.
Comment 9 Nils Philippsen 2006-03-14 17:00:26 EST
I've applied your patch in "upstream" CVS.
Comment 10 Nils Philippsen 2006-04-26 11:18:50 EDT
fixed in system-config-date-1.8.3 which should hit mirrors shortly.
Comment 11 Fedora Update System 2006-04-26 17:12:33 EDT
system-config-date-1.8.3-0.fc4.1 has been pushed for fc4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.
Comment 12 Satyabrata Maitra 2006-04-28 06:00:21 EDT
This problem has been solved. The Entries "Moscow+00 - west Russia" is
translated. And it is in the Third tab in system-config-date window, not in
second in the present version. 
Tested in the system-config-date version No. : system-config-date-1.8.3-1.
Comment 13 Satyabrata Maitra 2006-04-28 06:05:35 EDT
Created attachment 128353 [details]
Screenshot of the system config date window.

This bug has been fixed in the system-config-date-1.8.3-1 version. The
specified entries are translated.

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