Bug 206100 - problem in POT file
Summary: problem in POT file
Alias: None
Product: Fedora
Classification: Fedora
Component: tzdata
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Petr Machata
QA Contact:
Keywords: StringChange
Depends On:
TreeView+ depends on / blocked
Reported: 2006-09-12 04:21 UTC by A S Alam
Modified: 2015-05-05 01:32 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2006-09-12 12:23:29 UTC

Attachments (Terms of Use)
POT file attaching (18.52 KB, text/plain)
2006-09-12 11:00 UTC, A S Alam
no flags Details
fixed version of the affected file (18.32 KB, text/plain)
2006-09-12 11:36 UTC, Petr Machata
no flags Details

Description A S Alam 2006-09-12 04:21:18 UTC
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?


Comment 1 Petr Machata 2006-09-12 08:36:11 UTC
Where does the affected timezones.pot come from? I can't replicate the problem.

Comment 2 Petr Machata 2006-09-12 08:48:20 UTC
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 09:57:11 UTC
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 10:39:55 UTC
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 10:59:03 UTC
I checked out from following server:

[aalam@aalam timezones]$ cat CVS/Root

Comment 6 A S Alam 2006-09-12 11:00:01 UTC
Created attachment 136066 [details]
POT file attaching

Comment 7 Petr Machata 2006-09-12 11:35:46 UTC
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 11:36:57 UTC
Created attachment 136067 [details]
fixed version of the affected file

File with removed duplicates.

Comment 9 A S Alam 2006-09-12 12:23:29 UTC
commited to CVS, thanks

Comment 10 Nils Philippsen 2006-09-13 13:11:44 UTC
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 14:45:39 UTC
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 16:37:01 UTC
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 17:13:44 UTC
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 17:18:27 UTC
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 18:19:41 UTC
Ok, then I have no objections.

Comment 16 Nils Philippsen 2006-09-13 18:43:23 UTC
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 16:22:23 UTC
(the discussion continues by mail)

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