diff options
Diffstat (limited to '')
| -rw-r--r-- | comm/docs/l10n/fluent_migrations.md | 190 | ||||
| -rw-r--r-- | comm/docs/l10n/index.md | 16 | ||||
| -rw-r--r-- | comm/docs/l10n/testing_migrations.md | 39 |
3 files changed, 245 insertions, 0 deletions
diff --git a/comm/docs/l10n/fluent_migrations.md b/comm/docs/l10n/fluent_migrations.md new file mode 100644 index 0000000000..13639ca187 --- /dev/null +++ b/comm/docs/l10n/fluent_migrations.md @@ -0,0 +1,190 @@ +# Migrating Strings to Fluent Files + +Like [Firefox](https://firefox-source-docs.mozilla.org/l10n/migrations/index.html), +Thunderbird developers are working on migrating strings from legacy formats to +Fluent. The process is very similar to how migrations are done for Firefox. The +differences are detailed below. + +## Migration Recipes + +When part of Thunderbird’s UI is migrated to Fluent, a migration recipe should +be included in the same patch that adds new strings to .ftl files. Recipies are +stored in [comm-central](https://hg.mozilla.org/comm-central/file/tip/python/l10n/tb_fluent_migrations). +After a patch with migrations landed, it will be run for all locales as part of +the [Thunderbird Cross-Channel string quarantining process](cross_channel.md). + +Be sure to read [Migrating Legacy Formats](https://firefox-source-docs.mozilla.org/l10n/migrations/legacy.html) +along with the below example. + +The migration recipe’s filename should start with a reference to the associated +bug number, and include a brief description of the bug, e.g. `bug_1805746_calendar_view.py` +for the below example. + +### Example: Migrate Multiple DTD strings to Fluent + +Often, strings are migrated as part of ongoing UI work to convert XUL code +to HTML. Multiple DTD strings may convert to a single Fluent string with +attributes. It really depends on the document structure and what the UI changes +are doing. + +**Legacy strings are in `comm/calendar/locales/en-US/chrome/calendar/calendar.dtd`** + +```dtd +<!ENTITY calendar.day.button.tooltip "Switch to day view" > +<!ENTITY calendar.day.button.label "Day" > +``` + +**The (simplified) XUL code** + +```xml +<radio id="calendar-day-view-button" + label="&calendar.day.button.label;" + tooltiptext="&calendar.day.button.tooltip;" /> +``` + +**The new HTML** + +```html +<button id="calTabDay" data-l10n-id="calendar-view-toggle-day"></button> +``` + +**The new FTL string** + +```fluent +calendar-view-toggle-day = Day + .title = Switch to day view +``` + +**Renders as:** + +```html +<button id="calTabDay" title="Switch to day view">Day</button> +``` + +This case migrates two DTD strings, `calendar.day.button.label` and `calendar.day.button.tooltip` +to create a single FTL string, `calendar-view-toggle-day`, with one (`title`) +attribute. + +**The migration recipe:** + +```python +# Any copyright is dedicated to the Public Domain. +# http://creativecommons.org/publicdomain/zero/1.0/ + +from fluent.migratetb.helpers import transforms_from +from fluent.migratetb import COPY + +def migrate(ctx): + """Bug 1805746 - Update Calendar View selection part {index}.""" + target = reference = "calendar/calendar/calendar-widgets.ftl" + source = "calendar/chrome/calendar/calendar.dtd" + + ctx.add_transforms( + target, + reference, + transforms_from( + """ +calendar-view-toggle-day = { COPY(from_path, "calendar.day.button.label") } + .title = { COPY(from_path, "calendar.day.button.tooltip") } +""", + from_path=source, + ), + ) +``` + +Migrations are Python modules, and implement +a single `migrate(MigrationContext)` function. The `migrate()` function makes +calls into `MigrationContext.add_transforms()`. + +The `add_transforms()` function takes three arguments: +- `target_path`: Path to the target l10n file +- `reference_path`: Path to the reference (en-US) file +- A list of Transforms, the `source_path` (legacy translated strings file) is + set here + +```{note} +For Thunderbird migrations, the target and reference path are the same. +``` + +Transforms are rather dense AST nodes. See +[Transforms](https://firefox-source-docs.mozilla.org/l10n/migrations/overview.html#transforms) +for the exact details. + +There are some helper functions that simplify creating the ASTs. The above example uses the +`transforms_from()` helper function. It is equivalent to: + +```python +target = reference = "calendar/calendar/calendar-widgets.ftl" +source = "calendar/chrome/calendar/calendar.dtd" + +ctx.add_transforms( + target, + reference, + [ + FTL.Message( + id=FTL.Identifier("calendar-view-toggle-day"), + value=COPY(source, "calendar.day.button.label"), + attributes=[ + FTL.Attribute( + id=FTL.Identifier("title"), + value=COPY( + source, + "calendar.day.button.tooltip" + ) + ) + ] + ) + ] +) +``` + +`transforms_from()` allows copying reference FTL strings, and replacing the value +of each message with a `COPY` Transform that copies values from the DTD file at +`from_path`. + +There are other Transforms like `COPY`. See +[Migrating Legacy Formats](https://firefox-source-docs.mozilla.org/l10n/migrations/legacy.html) +for usage information. + +### Thunderbird migration helpers + +The `REPLACE` works with `transforms_from` if provided the extra context that +it needs. + +Starting with `aboutDialog.dtd` containing: + +```xml +<!ENTITY update.updateButton.label3 "Restart to update &brandShorterName;"> +``` + +```python +from fluent.migratetb.helpers import TERM_REFERENCE, transforms_from + +# This can't just be a straight up literal dict (eg: {"a":"b"}) because the +# validator fails... so make it a function call that returns a dict.. it works +about_replacements = dict({ + "&brandShorterName;": TERM_REFERENCE("brand-shorter-name"), +}) + + +def migrate(ctx): + """Bug 1816532 - Migrate aboutDialog.dtd strings to Fluent, part {index}""" + target = reference = "mail/messenger/aboutDialog.ftl" + source = "mail/chrome/messenger/aboutDialog.dtd" + + ctx.add_transforms( + target, + reference, + transforms_from( + """ +update-update-button = { REPLACE(source, "update.updateButton.label3", about_replacements) } + .accesskey = { COPY(source, "update.updateButton.accesskey") } +""", source=source, about_replacements=about_replacements)) +``` + +The resulting `aboutDialog.ftl` will get: + +```ftl +update-update-button = Restart to update { -brand-shorter-name } + .accesskey = R +``` diff --git a/comm/docs/l10n/index.md b/comm/docs/l10n/index.md new file mode 100644 index 0000000000..7b29d4a270 --- /dev/null +++ b/comm/docs/l10n/index.md @@ -0,0 +1,16 @@ +# Localization + +At Mozilla, localization refers to adapting the user interface and messages +to different cultural and regional needs. Localization is a broader term than +translation because it involves extensive research into the target culture, and +in result touches not only text and UI translation but also cultural adaptation +of icons, communication styles, colors, and UX. + +Questions about Thunderbird localization should be directed to the Localization +Coordinator. Contact information is on the +[Thunderbird Project page in Pontoon](https://pontoon.mozilla.org/projects/thunderbird/info/). + +```{toctree} +fluent_migrations +testing_migrations +``` diff --git a/comm/docs/l10n/testing_migrations.md b/comm/docs/l10n/testing_migrations.md new file mode 100644 index 0000000000..828b036c5a --- /dev/null +++ b/comm/docs/l10n/testing_migrations.md @@ -0,0 +1,39 @@ +# Testing Migration Recipes + +## During Development + +To test migration recipes during development, use the following mach command: + +```bash +./mach tb-fluent-migration-test comm/python/l10n/tb_fluent_migrations/bug_1805746_calendar_view.py +``` + +This will analyze your migration recipe to check that the migrate function exists, +and interacts correctly with the migration context. Once that passes, it clones +`comm-strings-quarantine` into `$OBJDIR/comm/python/l10n`, creates a reference +localization by adding your local Fluent strings to the ones in +`comm-strings-quarantine` (essentially the first part of the cross-channel +process). + +It then runs the migration recipe, both as dry run and as actual migration. +Finally it analyzes the commits, and checks if any migrations were actually run +and the bug number in the commit message matches the migration name. + +It will also show the diff between the migrated files and the reference, ignoring +blank lines. + +You can inspect the generated repository further by looking in +`$OBJDIR/comm/python/l10n/bug_1805746_calendar_view/en-US`. + +## During Review + +During l10n review, migration scripts will be run against all Thunderbird locales. +Any problems will be reported back to the author as part of the regular code +review process in Phabricator. + +```{tip} +Plan on extra review time for migration scripts in case changes are needed. + +Ask the Thunderbird L10n coordinator in [#maildev](https://matrix.to/#/#maildev:mozilla.org) +or your manager if you run into problems. +``` |