Red Hat Bugzilla – Full Text Bug Listing
|Summary:||problem in POT file|
|Product:||[Fedora] Fedora||Reporter:||A S Alam <aalam>|
|Component:||tzdata||Assignee:||Petr Machata <pmachata>|
|Status:||CLOSED NEXTRELEASE||QA Contact:|
|Version:||rawhide||CC:||katzj, mnewsome, mshao, nphilipp|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-09-12 08:23:29 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description A S Alam 2006-09-12 00:21:18 EDT
Description of problem: Timezone POT file showing error message from Terminal ------------ [aalam@aalam timezones]$ msgfmt -cvv timezones.pot timezones.pot:215: duplicate message definition timezones.pot:213: ...this is the location of the first definition timezones.pot:236: duplicate message definition timezones.pot:234: ...this is the location of the first definition timezones.pot:455: duplicate message definition timezones.pot:453: ...this is the location of the first definition timezones.pot:491: duplicate message definition timezones.pot:489: ...this is the location of the first definition timezones.pot:1334: duplicate message definition timezones.pot:1332: ...this is the location of the first definition msgfmt: timezones.pot: warning: PO file header missing or invalid warning: charset conversion will not work msgfmt: found 6 fatal errors ------------ can you please check, so that Translation can contine without problem? thanks
Comment 1 Petr Machata 2006-09-12 04:36:11 EDT
Where does the affected timezones.pot come from? I can't replicate the problem.
Comment 2 Petr Machata 2006-09-12 04:48:20 EDT
Plus it's strange that the definitions are two lines apart. In the original file, as well as in the patch that I provided last week, the strings are three lines apart, following this pattern: msgid "string" msgstr "" msgid "another string" msgstr "" # etc...
Comment 3 A S Alam 2006-09-12 05:57:11 EDT
sorry, I forgot to apply patch, which you provide last day, meanwhile on 9Sept2006 - 'nphilipp' update POT file and may be problem with that.
Comment 4 Petr Machata 2006-09-12 06:39:55 EDT
Couldn't it be the case that the patch is already applied then? Where can I get the updated file, I'd like to check it, and in CVS's devel/ I still only see 1.8.5.
Comment 5 A S Alam 2006-09-12 06:59:03 EDT
I checked out from following server: [aalam@aalam timezones]$ cat CVS/Root :ext:firstname.lastname@example.org:/usr/local/CVS
Comment 7 Petr Machata 2006-09-12 07:35:46 EDT
That's weird. It looks like if parts of my patch were applied twice. Maybe there were some manual changes before the patch was applied, but after s-c-date 1.8.5 from devel CVS. But then I don't understand how the application passed. Anyway, removing the duplicates should fix this particular problem. I'll attach fixed version. Is the "PO file header missing or invalid" a problem, too?
Comment 8 Petr Machata 2006-09-12 07:36:57 EDT
Created attachment 136067 [details] fixed version of the affected file File with removed duplicates.
Comment 9 A S Alam 2006-09-12 08:23:29 EDT
commited to CVS, thanks
Comment 10 Nils Philippsen 2006-09-13 09:11:44 EDT
I'm a bit curious about this -- tzdata doesn't contain message catalogs, but system-config-date contains timezones.pot, so what?
Comment 11 Petr Machata 2006-09-13 10:45:39 EDT
So what? Well, that just it. tzdata doesn't contain message catalogs, and system-config-date contains timezones.pot. For me this means roughly this: translators are working on s-c-d, but the strings are fetched from tzdata package. I can provide the patches necessary to keep strings up to date. Please let me know if you need to e.g. update all .po files with the patches, not just timezones.pot, I can do that.
Comment 12 Nils Philippsen 2006-09-13 12:37:01 EDT
For post FC6 I'd like to propose ripping out the message catalog generation out of s-c-date and putting it into tzdata, so every new version of tzdata would bring its translations with it. Not only s-c-date does need these translations, but anaconda as well (Jeremy keeps does his own translation thing or imports them from s-c-date IIRC). If we'd do this, the timezones would always come with their translations, and applications that cope with timezone names in the UI could just use the tzdata message catalog. Currently the strings to be translated are picked from whatever system the "make update-po" is running on which is plainly gross. What do you think?
Comment 13 Petr Machata 2006-09-13 13:13:44 EDT
I'm more thinking along the lines of why are the translations not located at tzdata package at all. Could there be rpm dependency problem? tzdata is installed as one of the first packages, even glibc depends on it, and I think that shell or even /usr might not be available at the time of installation. If this isn't actual problem, let's move the translations to tzdata, where they belong anyway. If this is problem, I may manage the strings at s-c-d cvs? (Or whichever package, possibly dedicated, happens to carry the strings in the end.)
Comment 14 Jeremy Katz 2006-09-13 13:18:27 EDT
Having the translations in the tzdata package should be fine from the point of view of anaconda and installing.
Comment 15 Petr Machata 2006-09-13 14:19:41 EDT
Ok, then I have no objections.
Comment 16 Nils Philippsen 2006-09-13 14:43:23 EDT
There are some things we should agree upon though before we put this into tzdata: - where the translated strings should be kept, i.e. we need an upstream where translators can work in without too much hassle. I see that there is a "tzdata-base" tarball in tzdata already, perhaps the translations could go in there and the whole thing could be kept in evlis/rhlinux CVS. - what the strings to be translated should be. Currently they are the whole "Continent/Region/Country" string, but I think the parts should be translated separately, as this would reduce the amount of typing needed to be done by the translators and in turn the probabilty of errors.
Comment 17 Petr Machata 2006-09-14 12:22:23 EDT
(the discussion continues by mail)