812993 - Remove all en-US strings from HTML

Status: RESOLVED INCOMPLETE

(Firefox OS Graveyard :: Gaia::L10n, defect, P4)

Description

[Staś Małolepszy :stas]

We're reading them from *.en-US.properties anyways when the current locale is en-US.  For other locales, when launching an app for the first time, you can clearly see the English text for a split second before it changes to the localized one.

Comment 1

[Fabien Cazenave [:kaze]]

The problem is valid but I think the HTML files would be less readable if we dropped the built-in strings, and there are other ways to solve it, e.g.:

 * hide the content until the 'localized' event is sent (which is done by quite a few apps atm);
 * pre-compile all HTML files for each supported language (which is planned).

We could rename this bug accordingly.

Comment 2

[:Margaret Leibovic]

I would be in favor of removing the built-in strings to make it more obvious to developers where the strings are coming from, and to make it more noticeable when there has been a mistake with l10n (e.g. typo in the id). 

This would also make our l10n performance obvious to developers using en-US. I don't think it would hurt the readability of the HTML files, since desktop Firefox has been doing this forever, and developers get by fine.

(In reply to Fabien Cazenave [:kaze] from comment #1)
>  * pre-compile all HTML files for each supported language (which is planned).

The current approach proposed in bug 809600 is to just include a pre-processed JS object in the HTML file to use as a shortcut to get gL10nData, so the switching of strings in JS will still happen (although we'd get to that point much more quickly).

Comment 3

[Fabien Cazenave [:kaze]]

Margaret, if all content is hidden until the 

my understanding of our performance improvement work was that we should *both* make it quicker to use runtime l10n resources *and* pre-compile HTML files for each locale — like most templating engines do. If nobody is working on the latter, I’ll make sure we do in the next few days because that looks like a real priority to me.

The situation is comparable with bug 800374:
 • I wouldn’t take the risk of touching this for v1;
 • I’d feel much better if we addressed the real priorities first;
 • if you think it’s work it, feel free to submit a patch and nominate this bug for BB+.

Your arguments are valid and I don’t want to block any work on the l10n side. I’d prefer to focus on “real” performance improvements before addressing this bug, but if it gets a BB+ label I’ll review patches for it.

Comment 4

[Fabien Cazenave [:kaze]]

Margaret, my understanding of our performance improvement work was that we should *both* make it quicker to use runtime l10n resources *and* pre-compile HTML files for each locale — like most templating engines do. If nobody is working on the latter, I’ll make sure we do in the next few days because that looks like a real priority to me.

The situation is comparable with bug 800374:
 • I wouldn’t take the risk of touching this for v1;
 • I’d feel much better if we addressed the real priorities first;
 • if you think it’s work it, feel free to submit a patch and nominate this bug for BB+.

Your arguments are valid and I don’t want to block any work on the l10n side. I’d prefer to focus on “real” performance improvements before addressing this bug, but if it gets a BB+ label I’ll review patches for it.

Comment 5

[Fabien Cazenave [:kaze]]

ugh:
  if you think it’s work it → if you think it’s worth it

Comment 6

[:Margaret Leibovic]

(In reply to Fabien Cazenave [:kaze] from comment #3)

> ... *and* pre-compile HTML
> files for each locale — like most templating engines do. If nobody is
> working on the latter, I’ll make sure we do in the next few days because
> that looks like a real priority to me.

Yeah, no one has been working on this. Also, if we want to do that, we'll need to get Axel on board with bug 811540. The first step would definitely be just loading locale-specific HTML files with the JS we need (the DOM manipulation to translate really doesn't take very much time at all if the developer is smart about lazy-loading things).

> The situation is comparable with bug 800374:
>  • I wouldn’t take the risk of touching this for v1;
>  • I’d feel much better if we addressed the real priorities first;
>  • if you think it’s work it, feel free to submit a patch and nominate this
> bug for BB+.
> 
> Your arguments are valid and I don’t want to block any work on the l10n
> side. I’d prefer to focus on “real” performance improvements before
> addressing this bug, but if it gets a BB+ label I’ll review patches for it.

I agree this bug isn't a v1 priority. This bug isn't about performance (I doubt this change would make anything faster), but rather about making our logic clearer. In the case where l10n is slow, this will avoid the really weird behavior of seeing our en-US strings first, and it will also make developers notice that l10n is slow if it take a moment before their strings show up. I'm willing to be a lot of developers who develop in en-US don't know that this is a problem.

Comment 7

[Staś Małolepszy :stas]

Closing this bug as per the discussion at [1] where we decided to start migrating HTML progressively as we edit them.

[1]: https://groups.google.com/d/msg/mozilla.dev.gaia/XWPswH8nuuE/_IT4FGUS8NcJ