Re: modest proposal -- use po, but not mo?

From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Wed May 01 2002 - 01:30:02 EDT

  • Next message: Andrew Dunbar: "Re: resolution and zoom issues"

     --- Paul Rohr <paul@abisource.com> 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



    This archive was generated by hypermail 2.1.4 : Wed May 01 2002 - 01:32:07 EDT