Spinning this off of bug 809600. jhford and I found that a really promising approach to speed up l10n startup time is to process the .ini/.properties files during build time. Things we're doing: -Find all <link type="application/l10n" href="[some file path].ini"/> -Use .ini files to find .properties files and create a JSON object for each locale the same way l10n.js currently builds gL10nData -Stick each JSON object in a <script type="text/l10n" data-l10n-strings="[some locale]"/> in the processed html file (the html parser will ignore this invalid script type, this is a trick CoffeeScript uses) I'll also file a bug for updating l10n.js to use this pre-processed JSON if it's available. We'll keep the existing l10n.js logic as a fallback for debug mode, so that localizers can still edit a properties file then hit refresh to see their changes.

Can we get rid of the .ini files, too? :jhford, assuming there will be an all-locales files for Gaia, can you use that to look for specific .properties files?

To provide an update in this bug, the approach we decided to pursue is to create a different html file for each locale, loading the appropriate pre-processed l10n data in a JS object. Bug 811540 is about rigging the app:// protocol to magically load the correct html file depending on the locale, then in l10n.js we can check to see if we already have data for the locale we're trying to load (should be there unless the user is switching languages). We still need to answer some questions in bug 811540, but if that gets resolved, we should be ready to land the build changes for this.

I have opened https://github.com/mozilla-b2g/gaia/pull/6411 for reviewing the patch

(In reply to Staś Małolepszy :stas from comment #1) > Can we get rid of the .ini files, too? :jhford, assuming there will be an > all-locales files for Gaia, can you use that to look for specific > .properties files? That's out of the scope of this bug.

Now that bug 821691 landed, we don't need to do this.