Migrate all basic text actions l10n to Fluent
Categories
(Toolkit :: General, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox73 | --- | fixed |
People
(Reporter: zbraniecki, Assigned: zbraniecki)
References
Details
Attachments
(1 file)
In result of bug 1600528, we now have textActions.ftl. Let's migrate to it all of m-c.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
Welp, it actually removes 20 DTD calls from M1!
Comment 3•5 years ago
|
||
With this patch, when I enable in FX in a txt field the spell checking I get this error two times:
[Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.readUTF8URI]" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: resource://gre/modules/L10nRegistry.jsm :: this.L10nRegistry.loadSync :: line 759" data: no] L10nRegistry.jsm:759
Assignee | ||
Comment 4•5 years ago
|
||
With this patch, when I enable in FX in a txt field the spell checking I get this error two times:
Can you provide STR please?
Comment 5•5 years ago
|
||
Open https://searchfox.org/ then in one of the two text fields right click and tick Check Spelling
on. Now right click again (the Languages
menuitem should be shown now) and the errors appear.
Assignee | ||
Comment 6•5 years ago
|
||
Open https://searchfox.org/ then in one of the two text fields right click and tick Check Spelling on. Now right click again (the Languages menuitem should be shown now) and the errors appear.
This is present in central as well and is not specific to this patch.
The source of the exception is that somehow the try/catch
here https://searchfox.org/mozilla-central/source/intl/l10n/L10nRegistry.jsm#757-761 doesn't silence the error when we synchronously try to load the FTL file.
It's a red herring - we try to load it from the browser omni.ja first, and then from the toolkit's one where we find it. The first should throw, and it does, it just should be silenced.
You can file it as a new bug.
Comment 7•5 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #6)
It's a red herring - we try to load it from the browser omni.ja first, and then from the toolkit's one where we find it. The first should throw, and it does, it just should be silenced.
It's because it's NS_ERROR_FILE_NOT_FOUND
instead of the 2 errors that we're specifically looking for.
Comment 8•5 years ago
|
||
Filed bug 1605489 for the errors.
Comment 10•5 years ago
|
||
Backed out changeset 0267e42c0db5 (bug 1604960) for causing bc permafails
push that caused the backout: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&selectedJob=282548682&resultStatus=testfailed%2Cbusted%2Cexception%2Cusercancel%2Crunnable&revision=0267e42c0db5cdb265f916deb1824f70cb3bb287&failure_classification_id=2
backout: https://hg.mozilla.org/integration/autoland/rev/ad0df2bff76ff8e9d4fd7eedd7d190628027bbf3
Comment 11•5 years ago
|
||
Assignee | ||
Comment 12•5 years ago
|
||
Green try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=57fadc384c7d4d54017160b886d2c1c2412a34c6
Minor updates:
- In browser/components/places/content/places.xhtml one MACOS ifdef
delete
action switched - devtools/client/webconsole/test/browser/browser_console_context_menu_entries.js updated to new IDs.
Assignee | ||
Comment 13•5 years ago
|
||
Comment 14•5 years ago
|
||
Comment 15•5 years ago
|
||
bugherder |
Description
•