From: Dom Lachowicz (doml@appligent.com)
Date: Mon Apr 29 2002 - 17:45:56 EDT
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.
> - 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 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.
Thanks,
Dom
This archive was generated by hypermail 2.1.4 : Mon Apr 29 2002 - 17:50:32 EDT