[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
GNU gettext and incorrectly-marked "obsolete" entries
From: |
Kevin L |
Subject: |
GNU gettext and incorrectly-marked "obsolete" entries |
Date: |
Wed, 12 May 2004 17:17:08 GMT |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 |
I've got code that looks like this (pseudo):
char message_array[][] {
"KEY_1",
"KEY_2",
"KEY_3",
...
}
I'm using gettext to turn KEY_1 into a translated string:
char * key = message_array[2];
char * output_string = _(key);
Very similar to a Java ResourceBundle. Worked great until today when I
"up"graded to gettext 0.14.1.
With the new suite of tools: autoconf 2.59, automake 1.7.9, gettext 0.14.1, the
new build process marks the translations for KEY_1, KEY_2, etc. as "obsolete".
Right now my application is horribly broken without these translated strings
appearing in the output.
Digging into the docs for msgmerge, I can't see any way to force msgmerge NOT to
do this.
The very reason I'm using these obvious keys is so that I can quickly tell how
much has been translated. I WAS going to replace the keys with the default
English strings before I got to 1.0, but if I can't find a way to get msgmerge
to include these strings that aren't directly used then my users will be stuck
with English-only strings in some very important parts of the application.
That's a can of worms I really don't want to open.
Is there a hopefully trivial way to get the old behavior back? Or should I edit
and recompile msgmerge without the "obsolete" string marking?
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- GNU gettext and incorrectly-marked "obsolete" entries,
Kevin L <=