We had to remove l10n usage from the FlyWeb system addon because it was causing oranges on OSX 10.10 debug M-e10s(1) and M-e10s(2) tests. It did not seem to be due to issues in the code itself, and suggested issues in the underlying platform. For reference, here is the delta-patch (and try run) that adds l10n files (but doesn't reference them in any way) on top of the current system addon, and replicates the oranges: https://hg.mozilla.org/try/rev/33254b9d36ca326c2af3fa6fd8b639f3db90ca18 https://treeherder.mozilla.org/#/jobs?repo=try&revision=33254b9d36ca We should figure out what's going on and add a proper l10n impl for the addon.
Firefox::Translation is for the Automatic Translation feature. I agree there's no good component for this bug (should Flyweb have its own?), so moving to Core::Networking as most Flyweb bugs are there.
(In reply to :Felipe Gomes (needinfo me!) from comment #1) > so moving to Core::Networking as most Flyweb bugs are there. But they shouldn't be in Core::Networking unless necko subtree is somehow involved.
Michal, can you please suggest a proper component for this bug. I also search in bugzilla and I saw that bugs with [FlyWeb] are in Core: Networking.
(In reply to ovidiu boca[:Ovidiu] from comment #3) > Michal, can you please suggest a proper component for this bug. I also Maybe localization? But I really don't know. > search in bugzilla and I saw that bugs with [FlyWeb] are in Core: Networking. This is a common mistake. The code lives in DOM and IMO a new component "DOM: Flyweb" should be created.
Hi Pike, Ryan VanderMeulen suggest me to ping you about this issue. Can you help us finding the right place for this issue? Thanks
(In reply to ovidiu boca[:Ovidiu] from comment #5) > Hi Pike, Ryan VanderMeulen suggest me to ping you about this issue. Can you > help us finding the right place for this issue? > > Thanks I'll defer the answer to that to flod.
I believe this bug doesn't belong to the Mozilla Localization component as it stands, because it's not going to be fixed on the localization side of things. It belongs to the component where other FlyWeb bugs belong, and that still seems unclear based on previous comments (its own component sounds like a good idea to me). I also went back to bug 1272107 to check the discussion, and it's still unclear what are the expectations: is the development of FlyWeb going to follow the trains (i.e. aurora and beta are string frozen) or need to go faster than that? Is it going to need more than the two current strings?
One more note: if this needs to live in m-c, in order to get managed by compare-locales the folder needs to be listed in browser/locales/l10n.ini (see for example Pocket) http://hg.mozilla.org/mozilla-central/file/default/browser/locales/l10n.ini#l9
Kannan, this bug is and old stuck in untriaged. Could you please move it to the correct location so that it stops alerting and we know who's responsible for it? If you need help making a Core: Flyweb component, please reach out to Emma or myself.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > Kannan, this bug is and old stuck in untriaged. Could you please move it to > the correct location so that it stops alerting and we know who's responsible > for it? If you need help making a Core: Flyweb component, please reach out > to Emma or myself. Thanks for the suggestion, I think it's appropriate to make a FlyWeb component for this. How do we get that started?
Filed bug 1294191, requesting Toolkit->Flyweb.
[Tracking Requested - why for this release]: Release Note Request (optional, but appreciated) [Why is this notable]: [Affects Firefox for Android]: [Suggested wording]: [Links (documentation, blog post, etc)]:
[Tracking Requested - why for this release]:
not tracking for 52, no justification given in comment 12. and resetting status flags.