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
signature.asc
Description: This is a digitally signed message part
