Mon 08 Dec 2008 03:00:19 AM UTC, comment #2:
>> msgstr "": untranslated unless msgid "" and msgctxt is set
>
> There needs to be a distinction between translated and
> untranslated messages. For years, in PO files, this distinction
> is done by testing whether msgstr is empty or not. Also, when
> msgmerge adds a new message to a PO file, the translated must
> have a way to know that he needs to look at this message. One
> could, in theory, use the fuzzy flag to denote this. But the
> many PO file editors around would need to change for this; I
> don't think it's worth the effort.
A number of those editors haven't been updated to support msgctxt anyway. But for those that have, the rule I suggested would only affect a very small percentage of messages, even if the editor didn't support the fuzzy flag suggestion. But having the command-line tools know the difference would still be helpful.
> The translator can, for
> example, use a string with only a zero-width no-break space
> (or some other Unicode control character) instead of an empty
> string.
That's true, but probably not in all cases (eg lists of optional classes to be loaded). However, where it's appropriate, it could be used as a workaround with editors like those above.
The problem is, I'm dealing with some pretty general problems - Java .properties files contain a hodge-podge of translatable text, localisable configuration and unlocalisable configuration. It's unfortunate that Sun conflated the problems of configuration and localisation in Java!
I'm trying to map these things into po/pot files because (a) open source translators are often used to dealing with po/pot, not .properties and (b) a number of tools exist for processing and analysing po files (particularly the gettext-tools).
I can see I haven't made the case that empty msgids make sense, and without empty msgids, empty msgstrs don't make sense either.
> I think empty msgids are better avoided. After the step of
> preparing strings
>
> <http://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings>
> I can hardly see how empty msgids can appear.
In a normal gettext program, I would agree. But anything that tries to map .properties files into pot files will eventually run into an empty string, because .properties are such a mixture. To give some examples, most of the empty strings I've found in JBoss Tools have been gui titles and descriptions (presumably to be filled in later), but there are also empty lists of classnames and empty image names. It's possible that these lists/image names could be non-empty in some locales. As for the gui titles and descriptions, yes, they probably should be filled in, but it would be nice if the gettext-tools worked on translations which are being cleaned up.
Java codebases which have been internationalised without gettext tend to use artificial property keys with the English text as the property value. They don't usually use the English text as the key, the way gettext encourages. The prop->po mapping used by msgcat --properties-input puts the English string into msgstr, but that doesn't work if you want to generate self-contained pot files, since the pot won't have the msgstr.
Now that gettext supports msgctxt, I think the mapping used in Ant-Gettext (or prop2po --duplicates=msgctxt) makes better sense for such codebases, since it preserves both the property key and the English text from the .properties file, in the pot. (Perhaps I should raise a bug against msgcat for a new option?)
Even though the .properties format is quite ugly, I don't have much chance of convincing Java developers to accept po/pot unless it supports the way they already work. And I would like to standardise on po/pot if I can, if only to avoid proliferation of translation formats. With this tweak, I think the po format would work quite well in this situation.
Would you accept a patch for this if I developed one?
|