Closed Bug 1402061 Opened 3 years ago Closed 3 years ago
[tracking] Soft-launch the new localization API
First milestone on the path to enable the new localization API (bug 1365426) is defined as: ``` In this phase we intent to introduce a single, new, trivial message using Fluent into Firefox. That will require all core systems to work like LocaleService, Intl, L10nRegistry, Fluent, Fluent-DOM, and Fluent-Gecko. On top of that, we'll need compare-locales, and pontoon support. In this phase we will intentionally keep the new API under control with a whitelist of enabled .ftl files to remove the risk of engineers starting to use our API prematurely. ``` This bug will track the effort toward the soft launch.
Priority: -- → P3
In the light of bug 1402069, I'm wondering if there's a explicit list of things outside of scope. Notably, the way that that bug's currently coded it won't cover FOUC, and I would like to know which milestone is covering that. Also, live language switching. Both of those are non-perf runtime features, are there more? Maybe a11y, bug 1394882, for just screenreading? IIRC, we had most a11y for accesskeys etc.
> I'm wondering if there's a explicit list of things outside of scope. I don't think we have a list like that. Everything that is not set as blocking this milestone, is by definition out of scope for this bug. I follow this list for milestones: https://docs.google.com/spreadsheets/d/1ubpXFL9UMT9TgN76M3Jm8rGhDUFP6mLJrStbqJlY1M0 > Notably, the way that that bug's currently coded it won't cover FOUC, and I would like to know which milestone is covering that. Depending on what codebase we'll pick for the first migration FOUC may block first migration and definitely would block open migration. My take is that soft-launch is mainly to test the infrastructure, first-migration is to test our migration code, and open migration is a hard stop for any FOUCs. > Also, live language switching. Live language switching is a new feature and we can transition from the current l10n to L20n without it, so my initial take is to not block on it... Saying that, I just run a simple test on this patch and it nicely switched back and forth between en-US build and a polish langpack on fly :) > Maybe a11y, bug 1394882, a11y is a blocker for open-migration as per the spreadsheet. I'll be filing bugs for the remaining milestones soon and will try to take all bugs that block 1365426 and assign them to one of the milestones. Does it answer your questions?
If all of these things shouldn't be part of the first milestone, then we might not want to use a declarative string as first one, but a programmatic one. Maybe a desktop notification or so, where timing is more "shoot and forget" than "I need this to be here right now".
Makes sense. Flod - do you have any string like that coming to your mind?
I'm having a hard time following the line of thoughts here, e.g. "declarative" vs "programmatic". Would the accessibility.warn_on_browsewithcaret dialog be a good fit? It's as hidden as it can get, but it's not one string, it's five (for some reason "Yes" is defined there, but "No" is not). https://hg.mozilla.org/mozilla-central/file/default/toolkit/locales/en-US/chrome/global/browser.properties#l5
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.