Move home button confirmation prompts to fluent and out of browser.properties
Categories
(Firefox :: Toolbars and Customization, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox138 | --- | fixed |
People
(Reporter: Gijs, Assigned: shane.a.ziegler, Mentored)
References
Details
Attachments
(1 file)
After the refactor in bug 1954799 the module is still relying on window.gNavigatorBundle.
It would be nice to migrate those strings to fluent. The strings are here: https://searchfox.org/mozilla-central/rev/dd8b5213e4e7760b5fe5743fbc313398b85f8a14/browser/locales/en-US/chrome/browser/browser.properties#8-10 .
There's documentation on how to do the migration in https://firefox-source-docs.mozilla.org/l10n/migrations/index.html .
You'd probably want to lazily construct a new Localization object in the module, e.g. like https://searchfox.org/mozilla-central/rev/dd8b5213e4e7760b5fe5743fbc313398b85f8a14/browser/actors/EncryptedMediaParent.sys.mjs#20-22 , passing just 1 FTL file (to be added in this patch, with just those 3 strings in). Then you can use that object to formatValues() to asynchronously get the localized copy that you want to pass into the dialog API (the Services.prompt.confirmEx call). The method would need to become async so we can await that async call, but that should be fine.
|
Assignee | |
Comment 1•8 months ago
|
||
I am working patch for this.
|
|
Assignee | |
Comment 2•8 months ago
|
||
|
||
Updated•8 months ago
|
|
|
Assignee | |
Comment 3•8 months ago
|
||
Moved the home button confirmation prompt string messages to Fluent. browser/locales/en-US/browser/toolbarDropHandler.ftl
Updated browser/components/customizableui/ToolbarDropHandler.sys.mjs file to pull prompt from Fluent instead of window.gNavigatorBundle / browser.properties
Made python/l10n/fluent_migrations/bug_1955586_toolbardrophandler.py file for localizations team use.
Ran ./mach fluent-migration-test on it, seemed ok, but I am not totally sure what to look for. No diffs were output during test.
Noticed that browser.properties file had numerous lines where spaces were removed from legacy key/value pair before and after = sign. Hopefully, this is fine? Think this was caused by running properties-to-ftl migration tool?
|
Reporter | |
Comment 4•8 months ago
|
||
(In reply to Shane Ziegler from comment #3)
Moved the home button confirmation prompt string messages to Fluent. browser/locales/en-US/browser/toolbarDropHandler.ftl
Updated browser/components/customizableui/ToolbarDropHandler.sys.mjs file to pull prompt from Fluent instead of
window.gNavigatorBundle/browser.properties
\o/
Made
python/l10n/fluent_migrations/bug_1955586_toolbardrophandler.pyfile for localizations team use.
Ran./mach fluent-migration-teston it, seemed ok, but I am not totally sure what to look for. No diffs were output during test.
From what I remember, that sounds right to me, but the fluent-reviewers will check. :-)
Noticed that
browser.propertiesfile had numerous lines where spaces were removed from legacy key/value pair before and after=sign. Hopefully, this is fine? Think this was caused by runningproperties-to-ftlmigration tool?
Ah, hm, that isn't ideal. Can you revert this part? Using hg you can use something like hg uncommit --interactive --revert browser/locales/en-US/chrome/browser/browser.properties and it will let you decide which parts of the change you want to remove (which is basically all of them except the removal of the first 3 strings at the top). Then re-submit to phab and the change should be gone. I'm sure git supports something similar if that's what you're using but I'm not well-versed enough in git lore to tell you exactly what it is...
|
|
Assignee | |
Comment 5•8 months ago
|
||
I reverted browser.properties back to original, removed the 3 lines related to the changes, and re-commited. The changes to the spaces, seems to be fixed now.
|
|
Reporter | |
Comment 6•8 months ago
|
||
Cool, thanks! Looks like you've had some feedback from bolsson. :-)
|
|
Assignee | |
Comment 7•8 months ago
|
||
Can you land the bug for me?
|
|
Assignee | |
Updated•8 months ago
|
|
||
Comment 9•8 months ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 10•8 months ago
|
||
Gijs, Do you have any other patches I can work on?
|
|
Reporter | |
Comment 11•8 months ago
|
||
(In reply to Shane Ziegler from comment #10)
Gijs, Do you have any other patches I can work on?
Hey Shane! Sorry for the lack of response here - I don't know if Stephanie has shared but I have some ongoing health ups-and-downs so have been out since Wednesday. I'll get back to you on Monday, if that's okay. Sorry for the trouble.
|
|
Reporter | |
Comment 12•7 months ago
|
||
(In reply to Shane Ziegler from comment #10)
Gijs, Do you have any other patches I can work on?
Sorry, took a bit, but I just filed bug 1957495 and assigned it to you. The first step is not so exciting, pulling another bit of code into a module. But once it's in a singleton module we can hopefully take advantage and optimize the code a bit more so that opening new windows can reuse information from previous windows.
Description
•