mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-24 13:21:05 +00:00
ed0c600d94
To support and enable the migration, quite a bit of refactoring is needed. Many of the localised error messages are in fact fragments of HTML, including messages with nesting not supported by Fluent. In the FTL, these have each been split up into multiple messages using a custom migration transform (included directly in the script). This allows for localisers to work with the messages without HTML syntax, but does require the messages' structures to be maintained elsewhere. To that effect, the JS file represents messages as arrays of `[tagName, l10nId, l10nArgs]` tuples from which it builds the messages' elements. This fixex bug 1621895. Though extensive, the refactoring done here is for the most part limited to what's required by the Fluent migration. For instance, not all issues raised in bug 1722896 are resolved here. Places where the structure was sufficiently messy to have introduced bugs or dead code have been cleaned up a bit, though. This variant of netError that's used by the browser is not itself overridden by anyone else, which allows for it to be tackled first and independently of the docshell and mobile variants. As a part of its content is still passed in as a query parameter, it's possible that later refactors of the rest of the netError system will allow for further clean-up here. Differential Revision: https://phabricator.services.mozilla.com/D155951 |
||
|---|---|---|
| .. | ||
| devtools/migrate-l10n | ||
| docs | ||
| gdbpp/gdbpp | ||
| l10n | ||
| lldbutils | ||
| mach | ||
| mozboot | ||
| mozbuild | ||
| mozlint | ||
| mozperftest | ||
| mozrelease | ||
| mozterm | ||
| mozversioncontrol | ||
| sites | ||
| mach_commands.py | ||
| moz.build | ||
| README | ||
This directory contains common Python code. The basic rule is that if Python code is cross-module (that's "module" in the Mozilla meaning - as in "module ownership") and is MPL-compatible, it should go here. What should not go here: * Vendored python modules (use third_party/python instead) * Python that is not MPL-compatible (see other-licenses/) * Python that has good reason to remain close to its "owning" (Mozilla) module (e.g. it is only being consumed from there). Historical information can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=775243 https://bugzilla.mozilla.org/show_bug.cgi?id=1346025