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)