Document the weekly locale extraction process better #2544
Conversation
|
@muffinresearch TBH I wasn't sure what to say in the case where fuzzy strings are in the merge diff |
docs/i18n.md
Outdated
| `# fuzzy`. This comment means the localization may not exactly match the source text; | ||
| a localizer needs to review it. | ||
| For applications like `disco` (The Discovery Pane) you may not want | ||
| to merge a pull request until the fuzzy strings are resolved. |
There was a problem hiding this comment.
You really have to merge them or localizers won't see them / or fix them.
I think the main points are about checking that the fuzzy markers are expected. E.g. you'd expect to see them when you extract a new string that's a partial match to a key that already exists.
Developers should look out for where code changes cause translations to be marked fuzzy e.g. by changing the copy or changes to the extraction code. In exceptional cases you may prefer to remove fuzzy markers manually to avoid falling back to an english string even if the resulting translation isn't exact any more.
Removing the fuzzy marker manually will make it less obvious to translators that the translation needs updating so use that option with care and or contact the localizers mailing list to let them know.
An important point is that a fuzzy marked translations will not be used in the application by default. This is controlled by config. Allowing fuzzy translations would almost always result in bad translations being used in the application so turning that on should be done with caution.
| Request a review for the pull request and merge it like any other. | ||
| If necessary, repeat the process for the next application. | ||
|
|
||
| ### Building the JS locale files |
There was a problem hiding this comment.
You could note that this part is now automatically run for deployments and tests.
|
Thanks for doing this. |
Closes mozilla/addons#10458