Re: RFP: externalize *all* locale-specific information

From: Andrew Dunbar (hippietrail@yahoo.com)
Date: Mon Apr 29 2002 - 23:56:28 EDT

  • Next message: Andrew Dunbar: "Re: RFP: externalize *all* locale-specific information"

     --- Dom Lachowicz <doml@appligent.com> wrote: > Just
    to chime in:
    >
    > > - locale bloat ... redundant storage of all
    > those english strings
    >
    > Not a problem really. Before we were storing
    > XAP_STRING_ID_XYZ inside
    > the XML file, and then doing some C++ macro-madness
    > to map it back to an
    > integer id. Now we need to "redundantly" store the
    > english strings
    > inside of po files. It seems about the same to me -
    > you do need at least
    > 2 bits of data to properly create a map, after all.

    I'm not worried about locale bloat either. If there's
    something wrong with the translated strings it's a
    good thing for there to always be working English
    strings built in. Better than all blanks (:

    > > - app bloat ... given that we already link an
    > XML parser, the rest of
    > > the strings mechanism is almost certainly
    > lighter weight than
    > > the gettext library
    >
    > Definitely true, though gettext isn't very large at
    > all. Kenneth
    > Christiansen has an XML version of something very
    > much like gettext,
    > which we might want to look into too.
    >
    > > - speed ... ID lookups should be faster than
    > atomized string keys
    >
    > We'll still do ID lookups. I plan on keeping the
    > integer IDs around and
    > keep our exposed XAP_StringSet exposed interface
    > just about (if not)
    > 100% intact. I do plan on making some additions to
    > convert strings
    > transparently into some given locale via
    > getString(). I plan to make a
    > map of integer id->en_us string. gettext provides
    > the en_us
    > string->xx_yy string map for us, including

    So what happends when two IDs have the same en-US
    string but fit into different contexts and have
    different translations?

    > intelligent fallbacks (which
    > our current stringsets don't handle). With those 2
    > tidbits of data, you
    > can see how I can trivially make a map of integer
    > id->xx_yy string,
    > which is what we have currently. Now if I preload
    > those strings on
    > application startup (XAP_App or AP_App
    > initialization), we now have
    > exactly the same situation as with the XML strings.

    I'm also wondering just how the language tags are
    handled by gettext. I filed an RFE the other days to
    extend the language tags. At the time I was thinking
    mostly about spellchecking, but it's probably valid
    anywhere. Does gettext use 2-letter or 3-letter
    language codes? Neither are enough to work with
    http://bugzilla.abisource.com/show_bug.cgi?id=3227
    and I've not heard any mention of another upgrade to
    ISO 639.

    Something to think about. Andrew Dunbar.
     
    > Thanks,
    > Dom
    >

    > ATTACHMENT part 2 application/pgp-signature
    name=signature.asc
     

    =====
    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 : Mon Apr 29 2002 - 23:58:24 EDT