Bug 1642415 Comment 41 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #40)
> > I don't know if that fixes the case from comment #32 where the preferred locale does not match the build locale.
> 
> I'm concerned that there's some remaining underlying bug. Even in the worst case scenario, as far as I understand, we should still not blow up the search to that magnitude. If your langpack has missing files, L10nRegistry should just add another fallback, not 1000 of them.

There aren't missing files, just missing strings, so all the bundles are valid, but `formatWithFallbackSync` continues going through the bundle iterator. All the files exist in at least 2 filesources - the langpack and the app. browser.xhtml asks for 15 ftl files. So for each of those files, there are 2 options. So the total number of possible bundles is on the order of 2 to the power of 15. The fact that we find one that works after 2 to the power of 10 "already" presumably has to do with whether the messages missing from the langpack are in the first or the 15th file in the list. But I don't see any reason way in which we could "shortcut" this generation process, because the registry is oblivious to the messages required from each resource and thus can't guide its search for a "winning" bundle combination. Am I missing something?
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #40)
> > I don't know if that fixes the case from comment #32 where the preferred locale does not match the build locale.
> 
> I'm concerned that there's some remaining underlying bug. Even in the worst case scenario, as far as I understand, we should still not blow up the search to that magnitude. If your langpack has missing files, L10nRegistry should just add another fallback, not 1000 of them.

There aren't missing files, just missing strings, so all the bundles are valid, but `formatWithFallbackSync` continues going through the bundle iterator (until it finds one with 0 missing translations). All the files exist in at least 2 filesources - the langpack and the app. browser.xhtml asks for 15 ftl files. So for each of those files, there are 2 options. So the total number of possible bundles is on the order of 2 to the power of 15. The fact that we find one that works after 2 to the power of 10 "already" presumably has to do with whether the messages missing from the langpack are in the first or the 15th file in the list. But I don't see any reason way in which we could "shortcut" this generation process, because the registry is oblivious to the messages required from each resource and thus can't guide its search for a "winning" bundle combination. Am I missing something?

Back to Bug 1642415 Comment 41