Usually, a new release of our Android products means an update to strings. If this is the case, pull requests will be made throughout the release cycle by the mobile team, in order to land these new strings in the android-l10n repository in mozilla-l10n.
The PRs (also marked as quarantine) are reviewed by an l10n-driver - most often by the PM in charge of the project.
Let’s go over some of the steps needed over time in order to review strings correctly for a new release.
Let's consider Firefox for Android as an example - in fact, these apply to other Android products as well, and they also follow the same train schedule. During the Android l10n cycle, the Android team will make pull requests, in order to land new strings for the upcoming release.
Let’s consider a past PR here.
The first file present is _meta/mozilla-mobile-fenix.json. This file is managed by the automation syncing content between code and l10n repositories, and it’s used to track which changeset from the fenix repository was used to export the strings in this pull requests. main is the name of the branch from which strings are extracted, fenix is the internal project name of Firefox for Android. Updates to the value of main can be ignored, while changes to the name of the branch need to be coordinated with developers and release engineering.
The second file - values/strings.xml - is the actual strings file, containing all needed updates.
The first string change adds attributes: string moz:removedIn="94" name="recently_bookmarked" tools:ignore="UnusedResources". You can ignore this kind of changes, as they will not affect localizations. They are a reminder for mobile developers that they will be safely able to delete a string once it has finished riding the Nightly/Beta/Release train, and is no longer needed in an upcoming version. More details here.
Changes to comments are irrelevant in terms of string updates, so they’re also OK.
The general review of strings, such as this one, remains about the same as the usual string review process for other Mozilla products.
Things to look out for:
- Unclear strings and missing localization comments: the best way to identify them is to translate the strings, only having the string and comment as context (not the entire file, or the bug). For example: is the word used both a noun and a verb in English? Is the ID clear enough to give context (e.g.
buttonLabel)? - String changes without new IDs. IDs in XML files are stored in the
nameattribute; for example, the ID of this string isbrowser_menu_customize_home. - Duplicated strings.
- Localization issues, like misused plural forms, unclear comments, etc.
In case of issues, you can comment and CC the developer who introduced the string(s) by checking under the corresponding Commits section (example here). This can be done directly in the corresponding mozilla-l10n GitHub PR where your review has taken place.
So you’ve reviewed the strings during the cycle, and the PR looks good - this means you can now merge the PR so the strings get exposed in Pontoon.
Pontoon (here for Firefox for Android and here for Focus for Android) should get the new strings automatically after a few minutes, but it’s always a good idea to double check just in case.
One last thing is to not forget to update the l10n completion deadline under Pontoon resources for each product.