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

From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Tue Apr 30 2002 - 03:30:10 EDT

  • Next message: Christian Biesinger: "Re: RFP: externalize *all* locale-specific information"

     --- Christian Biesinger <cbiesinger@web.de> 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.
    >
    > > 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"

    Us old Amiga guys like to rant about how our old
    platform had stuff right over a decade ago that still
    sucks on other platforms now. This looks like one.
    The Amiga localization system was very similar to the
    one AbiWord uses now. It used numerical IDs to map
    to localized strings so string folding could be
    avoided. It also had a comment field in the locale
    files so you could explain the context and most
    people used it. Looks like gettext is a lot less
    modern than what we were using in the late '80s ):

    Andrew Dunbar.

    > 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). If your
    > tool would put the same
    > string more than once in the file, this would
    > probably confuse translation
    > tools.
    >
    > > 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...
    >
    > > 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?
    >
    > Or would that be incompatible with the strings file
    > format? I've never
    > taken a look at them...
    >
    > > 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.
    >
    >
    >
    > --
    > "They that can give up essential liberty to obtain a
    > little temporary
    > safety deserve neither liberty nor safety."
    > --
    > Benjamin Franklin
    >

    > ATTACHMENT part 2 application/pgp-signature
     

    =====
    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 : Tue Apr 30 2002 - 03:32:08 EDT