On Thu, Apr 7, 2016 at 12:36 PM Axel Hecht <[email protected]> wrote: > On 06/04/16 14:17, [email protected] wrote: > > On Tuesday, April 5, 2016 at 12:53:21 PM UTC+1, Axel Hecht wrote: > >> On 05/04/16 13:10, Joe Walker wrote: > >>> Something else, we can't ship a product that needs to download an l10n > >>> pack on first run. So we're going to have to bundle the strings with > >>> the product, which means the lookup can always be synchronous. > >> Actually, that's one of the lessons from gecko that we brought into the > >> design. String look-ups must be fallible (see also the hello bustage we > >> just had on beta). Now, if a string fails, we need to look up a > >> fallback, which means that during the call, we'd have to do blocking > >> mainthread sync IO to get and parse the English strings. > >> Or we'd need to take the perf hit to always load and parse at least > >> twice as many strings in localized builds as we do in en-US. > >> > >> That's why all l10n getters are async in the next world of l10n. > > I'm not following you quite here. > > > > Is there a reason we couldn't just lookup the fallback strings when we > lookup the localized strings? Thus the IO wouldn't need to happen on the > main thread. > Then you'd have to do the loading and parsing of twice the amount of > files on startup, half of which you don't want to need in most of the > cases. >
Right, obviously. But that seems like a small cost compared with the massive cost (both to development and to live usage) of making every string lookup asynchronous. Do we have numbers on how long it takes to load a string file? Joe. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
