On 10/15/2013 06:06 PM, Benjamin Smedberg wrote: > Do we need this data for any language other than the language Firefox ships > in? Can we just include the relevant language data in each localized build of > Firefox, and allow users to get other language data via downloadable language > packs, similarly to how dictionaries are handled? > > Is it possible that some of this data (the collation tables?) should be in > all Firefox locales, but other data (currency and timezone names) is not as > important and we can ship it only in one language?
It seems a fairly bad thing to me for us to get into the habit of prioritizing certain languages above others. Technically, if the data is compiled into the code, this would mean language repacks would...not be repacks any more. If you had sidealong data files everywhere, then you could perhaps repack still. This might require some repacking adjustments, possibly. ICU provides a udata_setCommonData function that lets you load data from anywhere, so there's some flexibility here. It's worth noting we currently have no central "hook" to insert this call before ICU's ever used. We init ICU at startup, but that init-call is fast. Presumably this new call can't be so fast, because you have to page in all the ICU data. And if you can't delay that til ICU is used, there's really no difference between the current setup and a setup that calls udata_setCommonData at startup. Of course, this is all just software. :-) > As far as I can tell, the spec allows user agents to ship whatever languages > they need; the real question is what users and site authors actually need and > expect out of the API. (I'm reading the spec out of > http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts) Grunging through v8's code, I...think...they cull locale lists for stuff to some degree. Maybe to the language set they ship. I'm looking at https://code.google.com/p/chromium/codesearch#chromium/src/third_party/icu/README.chromium and honestly don't understand enough about ICU to fully grok the substantial set of changes they've made. > Also, we are currently duplicating the data tables on mac universal builds, > because they are compiled-in symbols. That means sync I/O on the main thread, and not well-optimized because it won't be part of the binary. Just to note. Jeff _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
