From: Raphael Finkel (raphael_at_cs.uky.edu)
Date: Mon Jan 26 2004 - 16:53:26 EST
I just tried out this idea of splitting po-file messages. I have good
news and bad news. The good news is that the ui-backport.pl program
properly maintains the separation as it builds the .strings file. The
bad news is that the update.pl fails with error messages when it tries
to merge the resulting .po file with any updates based on the .h files;
it won't accept multiple uses of the same msgid.
(1) Upgrade the programs that update.pl uses to allow multiple uses of
the same msgid. Advantage: Separation would work. Disadvantage: PO
editing tools might break. I don't use such tools; I just use a text
(2) Change the msgids when we need to disambiguate. Advantage: All
existing tools would work. Disadvantages: Someone would need to track
down all the current multiply-defined msgids (I can provide a list) and
change all the important ones by some sort of prefix. These changes
have to be made in the src directory. The English menus, which use
msgid as it is, would then show that prefix, too, which would look ugly.
(3) Live with a single translation for each msgid. Advantage: All
existing tools work. Disadvantage: In some languages, the resulting
strings will not be grammatical, although they would most likely still
(4) For those languages where this problem occurs, work from the
.strings file instead of the .po file. Advantage: Separation works.
Disadvantages: It is harder to keep up with changes to the source, which
often rewords messages, removes obsolete messages, and introduces new
There might be other options. I would prefer option (1) of those
> > > If one could split po-file messages, it would be really great but
> > > can somebody to assure it is safe to do so?
> > It is *not* safe to do. The 'msgid's in PO files should be unique,
> > and several tools expect them to be so (including PO editing tools).
> > There are solutions to this (typically using some sort of prefix
> > notation on the 'msgid's, such as 'File|New'), but they're not very
> > elegant ... :/
This archive was generated by hypermail 2.1.4 : Mon Jan 26 2004 - 16:54:56 EST