--- Paul Rohr <[EMAIL PROTECTED]> wrote: > 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.
It sounds like all the problems have solutions. But since we're doing this, isn't this the perfect time to get all of our translatable strings into one place? I belive we used to have three and we now have two right? wp/ap/xp/ap_TB_LabelSet_xx-XX.h and user/wp/strings/xx-XX.strings It's possibly also the time to think about localizing plugins: http://bugzilla.abisource.com/show_bug.cgi?id=3203 Andrew Dunbar. > Paul ===== http://linguaphile.sourceforge.net http://www.abisource.com __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
