From: Paul Rohr (paul@abisource.com)
Date: Tue Apr 30 2002 - 11:44:32 EDT
At 09:23 AM 4/30/02 +0200, Christian Biesinger wrote:
>On Mon, Apr 29, 2002 at 04:16:11PM -0700, Paul Rohr wrote:
>> 1. isolate the strings
>> -----------------------
>> Prepare the sources so that gettext can extract strings to a .PO file.
>> To make this work, I think we'd just need to redefine the existing
>> *String_id.h file macros.
>
>Actually, the only thing that needs to be done is put N_(...) around the
>literal strings there (and #define N_(x) x at the top), that should be
>enough for gettext to be able to extract the strings.
Cool. I love it when macros make life that easy. :-)
>> 2. translate them
>> ------------------
>> Have the translators work with and check in .PO files. (These are a
plain
>> text format, right?)
>
>Yes, plain text. They look like this:
>#: src/af/xap/xp/xap_String_Id.h:1234
>msgid "Some English String"
>msgstr "Localized string"
>
>Hm, I just realized that your approach does not help the case of identical
>english strings in different contexts. They'd get merged together (at
>least that's what the gettext tool does).
Argh. That's the gettext "feature" that Andrew and others are complaining
about.
>If your tool would put the same
>string more than once in the file, this would probably confuse translation
>tools.
Hmm. Given that translators are the folks who hate the feature, then I'd
think they'd see this as a worthwhile bug to get fixed in their favorite
tools.
But then I'd also expected that they'd care enough to gravitate towards
ID-centric tools, too. Shows that my intuition isn't always well-grounded,
at least in this area. ;-)
>> 3. transform the result
>> ------------------------
>> At *build time*, instead of running a gettext tool to create a .MO file,
>> run one that creates a strings file with the appropriate IDs.
>
>That would require a tool which has a mapping of IDs to strings...
That mapping shouldn't be too hard to get. The macroized header file where
all the strings are found *already* maps IDs to strings -- indeed, that's
what it's *for*. You "just" need to dereference appropriately.
>> NOTE: This means that people wouldn't have to create strings files by
>> hand any more. So long as we have a way to keep track of the encoding
(so
>> iconv can find it), that shouldn't be a problem.
>
>Couldn't your tool directly convert the strings from whatever encoding the
>.po is in (the header contains this info) to UTF-8 (or another one, being
>always the same) when generating the strings file?
Excellent. Thanks for confirming that .po files are sane enough to define
the encoding they're using.
And yes, moving the charset conversion from runtime (where it's done now) to
build time (as you suggest) might be helpful. It won't save us the
footprint cost of including iconv in the binary, but it might decrease the
working set on launch.
>Or would that be incompatible with the strings file format? I've never
>taken a look at them...
Strings files are XML and include an encoding declaration.
>> To make this work, we'd need two little tools -- one that creates or
>> updates a PO file given a pair of appropriately macroized string_id.h
files
>
>You could use the normal gettext tools for this, if you really mark them
>the way I suggested above.
Sweet. Thanks.
Paul
This archive was generated by hypermail 2.1.4 : Tue Apr 30 2002 - 11:45:27 EDT