L20n in Firefox

[Staś Małolepszy]

I created https://wiki.mozilla.org/L20n/Firefox where I'd like to
document the effort of porting Firefox to L20n. If you're not
familiar with the plan read the blog post [1]. The second part
targeted at Firefox front-end developers is coming this week.

The High Level Status paragraph has a very rough outline of different
areas that we need to cover. I'd like to break each area down into
milestones and I'll need everyone's help doing that.

I've been thinking about the landing strategy and how we've said we
considered the About window. I think you hit the nail on the head
when you put the About window in the first section. That was just a
proof of concept. We proved that all parts of the UI can be localized
with L20n (XUL, XBL, chrome HTML, content HTML). But it's not good
enough to hold the ground after the landing.

Axel and Zibi suggested offline that we pick a Talos measure and stick
to it. I agree. This should be the feature we'll land first too. I
created a l20n-ts-paint branch which is the minimal path that gets us
a single string localized with L20n (the URL bar placeholder). I
talked to Zibi and we think it would be best to convert
browser.{dtd,properties} into browser.ftl (around 1,500 strings to be
parsed in total) and start by localizing the following pieces of the
UI:

- the URL bar placeholder ("Search or enter address"),
- the Search bar placeholder ("Search"),
- the Menu bar labels ("File", "Edit", "View", etc.).

I doubt we'll be able to migrate all of browser.xul. Instead I think
we should factor in the hit we'll be taking from running both the old
and the new l10n solution in parallel. If we can get good perf
results with this, then it's only going to get better once we remove
the old solution.

If everyone agrees, I'll file a bug to get this done!

-stas


[1] https://blog.mozilla.org/l10n/2016/06/29/l20n-in-firefox-a-summary-for-localizers/
[2] https://github.com/mozilla/gecko-dev/compare/master...stasm:l20n-ts-paint

[Staś Małolepszy]

W dniu poniedziałek, 18 lipca 2016 12:29:30 UTC+2 użytkownik Staś Malolepszy napisał:

> Axel and Zibi suggested offline that we pick a Talos measure and stick
> to it. I agree. This should be the feature we'll land first too. I

> created a l20n-ts-paint branch [2] which is the minimal path that gets us

> a single string localized with L20n (the URL bar placeholder).

> [2] https://github.com/mozilla/gecko-dev/compare/master...stasm:l20n-ts-paint

I pushed to try from my l20n-ts-paint branch and the results are in. Here's the comparison between mozilla-central master branch (or default in hg parlance) and l20n-ts-paint which is based on top of it:

https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b1c1f909fdd7&newProject=try&newRevision=b5a6bbfc8a2b&framework=1

There are minor regressions in session-restore (20-25ms, +2%) and a bigger one (15ms, +5%) in tpaint. From the wiki [1]:

Tests the amount of time it takes the open a new window. This test
does not include startup time. Multiple test windows are opened in
succession, results reported are the average amount of time required
to create and display a window in the running instance of the browser.
(Measures ctrl-n performance.)

OTOH, ts_paint which opens and new window and waits for the testpage to load is on par.

The measurements were done on a branch with an async version of L10nRegistry.

We need to better understand what are we paying for. A number of possible culprits come to mind:

- we're running both the old and the new framework at the same time,
- we redo what the chrome registry does,
- we're async,
- we do more DOM modifications,
- we parse in JS,
- the resolver has complex logic and we might not be hitting the simple string optimizations,
- other?

I'm also considering choosing tabbrowser.xml as our first target. It's XUL/XBL, not too big [2] and has a few interesting quirks. For instance it dispatches events when a tab's title changes which is non-trivial to do in the async/mutation observer world. We talked to annevk about this and he suggested emitting an event after a volley of mutations which has the list of changes nodes in its details. I filed https://bugzil.la/1287403 for this.

What say you?

-stas

[1] https://wiki.mozilla.org/Buildbot/Talos/Tests#tpaint
[2] https://dxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/tabbrowser.properties

[Axel Hecht]

On 18/07/16 12:41, Staś Małolepszy wrote:
> W dniu poniedziałek, 18 lipca 2016 12:29:30 UTC+2 użytkownik Staś Malolepszy napisał:
>
>> Axel and Zibi suggested offline that we pick a Talos measure and stick
>> to it. I agree. This should be the feature we'll land first too. I
>> created a l20n-ts-paint branch [2] which is the minimal path that gets us
>> a single string localized with L20n (the URL bar placeholder).
>> [2] https://github.com/mozilla/gecko-dev/compare/master...stasm:l20n-ts-paint
> I pushed to try from my l20n-ts-paint branch and the results are in.

Thanks

> Here's the comparison between mozilla-central master branch (or default in hg parlance) and l20n-ts-paint which is based on top of it:
>
> https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=b1c1f909fdd7&newProject=try&newRevision=b5a6bbfc8a2b&framework=1
>
> There are minor regressions in session-restore (20-25ms, +2%) and a bigger one (15ms, +5%) in tpaint. From the wiki [1]:
>
> Tests the amount of time it takes the open a new window. This test
> does not include startup time. Multiple test windows are opened in
> succession, results reported are the average amount of time required
> to create and display a window in the running instance of the browser.
> (Measures ctrl-n performance.)
>
> OTOH, ts_paint which opens and new window and waits for the testpage to load is on par.
>
> The measurements were done on a branch with an async version of L10nRegistry.
>
> We need to better understand what are we paying for. A number of possible culprits come to mind:
>
> - we're running both the old and the new framework at the same time,
> - we redo what the chrome registry does,
> - we're async,
> - we do more DOM modifications,
> - we parse in JS,
> - the resolver has complex logic and we might not be hitting the simple string optimizations,
> - other?
>
> I'm also considering choosing tabbrowser.xml as our first target. It's XUL/XBL, not too big [2] and has a few interesting quirks. For instance it dispatches events when a tab's title changes which is non-trivial to do in the async/mutation observer world. We talked to annevk about this and he suggested emitting an event after a volley of mutations which has the list of changes nodes in its details. I filed https://bugzil.la/1287403 for this.
>
> What say you?
>
> -stas
>
> [1] https://wiki.mozilla.org/Buildbot/Talos/Tests#tpaint
> [2] https://dxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/tabbrowser.properties

I'm looking at
https://treeherder.mozilla.org/perf.html#/graphs?series=%5Bmozilla-inbound,e01d1e393493367fed5c0e0506c3e4207cda4107,1,1%5D&series=%5Bmozilla-inbound,80f9ee414d2bbedcb38937e90e9a961b95ea441b,1,1%5D&series=%5Bmozilla-inbound,29c253bef49b44be88ba4cf244e66d20ee02934c,1,1%5D&series=%5Bmozilla-inbound,c1b1c708a4991e8bfbcfed312c14b840ba1ac87a,1,1%5D,
and it seems that our values are within the common noise for these tests?

Alternative view, highlighting your test results against other try
pushes:
https://treeherder.mozilla.org/perf.html#/graphs?series=%5Btry,e01d1e393493367fed5c0e0506c3e4207cda4107,1,1%5D&series=%5Btry,80f9ee414d2bbedcb38937e90e9a961b95ea441b,1,1%5D&highlightedRevisions=b5a6bbfc8a2b
and
https://treeherder.mozilla.org/perf.html#/graphs?series=%5Btry,29c253bef49b44be88ba4cf244e66d20ee02934c,1,1%5D&series=%5Btry,c1b1c708a4991e8bfbcfed312c14b840ba1ac87a,1,1%5D&highlightedRevisions=b5a6bbfc8a2b.


For tpaint we're at the upper bound of the current data, but I'm not
sure that's a solid regression just yet. Session restore seems totally
within the regular noise for the test.

Axel

[Axel Hecht]

Additional thought:

If we could run Talos with known regressions, like slow parsing, or
string retrieval, we might have a better argument. Sadly, I didn't find
an sync sleep(100) or so ad-hoc.

Axel

[Staś Małolepszy]

An update on this: we now have a project integration repository [1] set up and we're very close to having the complete Menu bar ported to L20n/FTL [2].

Currently larch is set up with a a changeset from mozilla-central. I would like to suggest that we work in bugs and go through a proper review process before we land on larch. This will give us an opportunity to take another look at code that we landed in gecko-dev/l20n before MozLondon and land it selectively as needed. What do you think?

The first two candidates would then be L10nRegistry [3] and MessageContext [4] which are both required to land the migrated Menu bar.

Tools like git-cinnabar [5] exist to make it possible to work with hg repos from git. I tried going full-hg today and using bookmarks and MozReview [6] looks very promising. I might try doing that exclusively from now on.

Thanks,
Stas


[1] http://hg.mozilla.org/projects/larch/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1288406
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1280671
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1288639
[5] https://github.com/glandium/git-cinnabar/wiki
[6] http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview.html

[Staś Małolepszy]

Another week, another update!

With help from Axel and Zibi I was able to land the ported menubar in
the larch twig:

https://bugzilla.mozilla.org/show_bug.cgi?id=1288406#c63

While working on this bug I ran into a few issues which I'd like to
call out here. They will be important for the end-game goal of landing
the ported menubar in mozilla-central. It would be great if over next
two weeks someone could look into them in detail.

Bug 1292128 - TypeError: menuPopup is undefined in
browser/base/content/test/general/browser_page_style_menu.js
https://bugzilla.mozilla.org/show_bug.cgi?id=1292128

Bug 1291915 - Using OS() with [xul/key] breaks the key shortcut
https://bugzilla.mozilla.org/show_bug.cgi?id=1291915

Bug 1291695 - Missing { references } can break bindings
https://bugzilla.mozilla.org/show_bug.cgi?id=1291695

Bug 1288443 - Improve fallback for label attributes in XUL
https://bugzilla.mozilla.org/show_bug.cgi?id=1288443

I'll be back on August 17th and I'll be happy to take whatever remains
from the list. I will also focus on improving and documenting
MessageContext as part of my Sprint 5 goals:

https://wiki.mozilla.org/L20n/Firefox#Sprint_5:_August_16_.E2.80.94_August_21

I know Zibi plans to work on performance of L20n for XUL (using the
ported menubar) as well as L20n for chrome HTML in the coming days.
Here's are the relevant bugs for references. Zibi, can you file bugs
for chrome HTML as well, please?

Bug 1289530 - Evaluate the performance of Firefox's menubar in L20n
https://bugzilla.mozilla.org/show_bug.cgi?id=1289530

Bug 1289535 - Speed up l20n-chrome-xul
https://bugzilla.mozilla.org/show_bug.cgi?id=1289535

Onwards!
Staś

> _______________________________________________
> tools-l10n mailing list
> tools...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/tools-l10n