Closed Bug 1469339 Opened 4 years ago Closed 4 years ago
Expose edit menu strings through Fluent
59 bytes, text/x-review-board-request
We'd like to work on opening an 'edit' context menu from an HTML document, and since the menu will be created from JS it'd be better to access the strings from Fluent than from the dtd: https://searchfox.org/mozilla-central/rev/285da1fd7dcf67448b9175741fa330158edcff73/browser/locales/en-US/chrome/browser/browser.dtd#317-339.
Alternatively, this file might be be a target for conversion: https://searchfox.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/textcontext.dtd. The drawback is there's some XBL anon content usage for input-box, although we are going to convert that to a Custom Element in Bug 1470910. We'd want to expose it in toolkit/ which doesn't yet have any fluent files so see Bug 1411707 for how that needs to get registered in browser glue / build system.
See Also: → 1411707
:flod, please see the patch in Bug 1456852 for an example of how this would be used (specifically https://reviewboard.mozilla.org/r/255676/diff/3#index_header). I'd prefer to not do migration of existing consumers here (see Comment 1 and that we'd be blocked on Bug 1455649) - but should be able to ultimately migrate the various dtd and properties consumers to use the ftl version: https://searchfox.org/mozilla-central/search?q=select+all&path=%7Bproperties%2Cdtd%7D.
Migration of strings can happen without the migration of the calling code. I'm not sure if we should include accesskeys in generic strings, or if we should do terms generically, and do per-usecase accesskeys (by using term references in the target ftl files). As food for thought for flod.
Updated the patch showing how this would be used: https://reviewboard.mozilla.org/r/255674/diff/3#index_header
Assignee: nobody → bgrinstead
Status: NEW → ASSIGNED
Comment on attachment 8990803 [details] Bug 1469339 - Put strings needed for the edit context menu into ftl at toolkit/locales; https://reviewboard.mozilla.org/r/255848/#review263166 Interesting, I did comment last week in MozReview, but looks like it failed to publish in the bug :-\ Please make sure to add all missing equal sign after the message IDs., that's the only issue I spotted. Also chatted with Axel about his comment, and while it might be interesting to have accesskeys changing based on context, it also feel like over-engineering. The current patch uses the same approach we currently use with DTD, and it's been working so far. No need to write a migration for these strings, easier and safer to just retranslate them, given we have a few places in browser and toolkit with these commands. ::: toolkit/locales/en-US/toolkit/main-window/editmenu.ftl:4 (Diff revision 2) > +### This file contains the entities needed for the 'edit' menu > +### It's currently only used for the Browser Console > + > +editmenu-undo Note: you need an equal sign even if the string doesn't have a value, see for example https://hg.mozilla.org/l10n/gecko-strings/file/default/browser/browser/preferences/applicationManager.ftl#l9
Attachment #8990803 - Flags: review?(francesco.lodolo) → review+
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/d104946698b2 Put strings needed for the edit context menu into ftl at toolkit/locales;r=flod
You need to log in before you can comment on or make changes to this bug.