Red Hat Bugzilla – Bug 206100
problem in POT file
Last modified: 2015-05-04 21:32:43 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
Where does the affected timezones.pot come from? I can't replicate the problem.
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...
sorry, I forgot to apply patch, which you provide last day, meanwhile on 9Sept2006 - 'nphilipp' update POT file and may be problem with that.
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.
I checked out from following server: [aalam@aalam timezones]$ cat CVS/Root :ext:aalam@i18n.redhat.com:/usr/local/CVS
Created attachment 136066 [details] POT file attaching
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?
Created attachment 136067 [details] fixed version of the affected file File with removed duplicates.
commited to CVS, thanks
I'm a bit curious about this -- tzdata doesn't contain message catalogs, but system-config-date contains timezones.pot, so what?
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.
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?
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.)
Having the translations in the tzdata package should be fine from the point of view of anaconda and installing.
Ok, then I have no objections.
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.
(the discussion continues by mail)