-
Notifications
You must be signed in to change notification settings - Fork 687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(translate_messages
): filter and disable fuzzy translations
#6772
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cfm
added
the
i18n
Anything related to translation or internationalization of SecureDrop
label
Mar 15, 2023
4 tasks
"msgattrib --no-fuzzy" removes fuzzy entries from each translation catalog. "msgmerge --no-fuzzy-matching" prevents fuzzy entries from being added back when the translation catalog is updated from the template.
Rebased from |
legoktm
approved these changes
Apr 14, 2023
cfm
added a commit
that referenced
this pull request
May 31, 2023
…NOME Shell extension In the original (since lost) 1cfd35b, we treated the GNOME Shell extension as a separate "securedrop/extension" Weblate component with its own "translate-extension" command, replicating both "--extract-update" and "--compile" modes. In f3d3f04, we treated the GNOME Shell extension as an extension (sorry) of the main "securedrop/securedrop" component, taking advantage of Babel's mapping feature to interpret the ".js.in" file as JavaScript. Here we harmonize both approaches. "translate-desktop --extract-update" is now a two-step process, first via Babel over the ".js.in" JavaScript file, then as usual via xgettext over the ".j2.in" desktop templates. (This is logically reversed, but Babel appears to have no equivalent of xgettext's appending "--join-existing" mode.) "translate-desktop --compile" does the equivalent via Babel and then msgfmt as usual. NB. We also add "msgmerge --no-fuzzy-matching" after #6772, which required rebasing from "develop".
cfm
added a commit
that referenced
this pull request
May 31, 2023
…NOME Shell extension In the original (since lost) 1cfd35b, we treated the GNOME Shell extension as a separate "securedrop/extension" Weblate component with its own "translate-extension" command, replicating both "--extract-update" and "--compile" modes. In f3d3f04, we treated the GNOME Shell extension as an extension (sorry) of the main "securedrop/securedrop" component, taking advantage of Babel's mapping feature to interpret the ".js.in" file as JavaScript. Here we harmonize both approaches. "translate-desktop --extract-update" is now a two-step process, first via Babel over the ".js.in" JavaScript file, then as usual via xgettext over the ".j2.in" desktop templates. (This is logically reversed, but Babel appears to have no equivalent of xgettext's appending "--join-existing" mode.) "translate-desktop --compile" does the equivalent via Babel and then msgfmt as usual. NB. We also add "msgmerge --no-fuzzy-matching" after #6772, which required rebasing from "develop".
cfm
added a commit
that referenced
this pull request
May 31, 2023
…NOME Shell extension In the original (since lost) 1cfd35b, we treated the GNOME Shell extension as a separate "securedrop/extension" Weblate component with its own "translate-extension" command, replicating both "--extract-update" and "--compile" modes. In f3d3f04, we treated the GNOME Shell extension as an extension (sorry) of the main "securedrop/securedrop" component, taking advantage of Babel's mapping feature to interpret the ".js.in" file as JavaScript. Here we harmonize both approaches. "translate-desktop --extract-update" is now a two-step process, first via Babel over the ".js.in" JavaScript file, then as usual via xgettext over the ".j2.in" desktop templates. (This is logically reversed, but Babel appears to have no equivalent of xgettext's appending "--join-existing" mode.) "translate-desktop --compile" similarly does two passes with msgfmt, first to create the standard gettext directory layout and then to update the desktop templates. NB. We also add "msgmerge --no-fuzzy-matching" after #6772, which required rebasing from "develop".
cfm
added a commit
that referenced
this pull request
May 31, 2023
…NOME Shell extension In the original (since lost) 1cfd35b, we tried to treat the GNOME Shell extension as a separate "securedrop/extension" Weblate component with its own "translate-extension" command, replicating both "--extract-update" and "--compile" modes. In f3d3f04, we tried to treat the GNOME Shell extension as an extension (sorry) of the main "securedrop/securedrop" component, taking advantage of Babel's mapping feature to parse the ".js.in" file as JavaScript. Here we harmonize the two approaches. "translate-desktop --extract-update" is now a two-step process, first via Babel over the ".js.in" JavaScript file, then as usual via xgettext over the ".j2.in" desktop templates. (This is logically reversed, but Babel appears to have no equivalent of xgettext's appending "--join-existing" mode.) "translate-desktop --compile" similarly does two passes with msgfmt, first to create the standard gettext directory layout and then to update the desktop templates. NB. We also add "msgmerge --no-fuzzy-matching" after #6772, which required rebasing from "develop".
cfm
added a commit
that referenced
this pull request
May 31, 2023
…NOME Shell extension In the original (since lost) 1cfd35b, we tried to treat the GNOME Shell extension as a separate "securedrop/extension" Weblate component with its own "translate-extension" command, replicating both "--extract-update" and "--compile" modes. In f3d3f04, we tried to treat the GNOME Shell extension as an extension (sorry) of the main "securedrop/securedrop" component, taking advantage of Babel's mapping feature to parse the ".js.in" file as JavaScript. Here we harmonize the two approaches. "translate-desktop --extract-update" is now a two-step process, first via Babel over the ".js.in" JavaScript file, then as usual via xgettext over the ".j2.in" desktop templates. (This is logically reversed, but Babel appears to have no equivalent of xgettext's appending "--join-existing" mode.) "translate-desktop --compile" similarly does two passes with msgfmt, first to create the standard gettext directory layout and then to update the desktop templates. NB. We also add "msgmerge --no-fuzzy-matching" after #6772, which required rebasing from "develop".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Status
Ready for review
Description of Changes
Closes #6483:
msgattrib --no-fuzzy
removes fuzzy entries from each translation catalog.msgmerge --no-fuzzy-matching
prevents fuzzy entries from being added back when the translation catalog is updated from the template.Testing
make translate
.$LANG
, confirm that insecuredrop/translations/$LANG/LC_MESSAGES/messages.po
eachmsgid
markedfuzzy
has had itsmsgstr
cleared. For example, compare:git diff securedrop/translations/ar/LC_MESSAGES/messages.po | grep -A3 "fuzzy"
fuzzy
entries as "needs editing")You'll see a lot of other diffs, too, from strings that have changed in
develop
since the v2.5.0 localization cycle. You can ignore these.Deployment
Development-only change; no deployment considerations.