Skip to content
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

ext.i18n policy to fallback to untranslated string when interpolation fails #1764

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ewdurbin
Copy link

Implements ext.i18n.newstyle_fallback_interpolation policy which can be set to True to gracefully fallback to untranslated strings if an interpolation error occurs due to incorrectly or out-of-date named variables in translations.

Checklist:

  • Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
  • Add or update relevant docs, in the docs folder and in code.
  • Add an entry in CHANGES.rst summarizing the change and linking to the issue.
  • Add .. versionchanged:: entries in any relevant code docs.
  • Run pre-commit hooks and fix any issues.
  • Run pytest and tox, no tests failed.

@ewdurbin
Copy link
Author

If this is even remotely in a direction acceptable to maintainers, I'm happy to address the remaining items to make it mergeable.

@davidism
Copy link
Member

When I was looking at this earlier, I expected you'd be able to either pass custom functions to env.install_gettext_callables or env.install_gettext_translations. But it looks like the problem is that this only matters for the "new style" wrappers, so overriding the functions being wrapped isn't going to be able to get at the error that the fallback needs.

I think this fallback makes a lot of sense. It seems like it would almost always be preferable to show/format the original string rather than failing. The downside is that you no longer get errors, so it's harder to catch and fix the bad translation. Maybe this shouldn't be a configuration, and should show a warning when substitution fails.

@ewdurbin
Copy link
Author

Thanks for considering this @davidism! So you're suggesting it might be better to make this the default behavior and fire a warning when the fallback occurs? That certainly simplifies things from my decision to implement it as a policy so that it wouldn't change without opt in. Biased, since this behavior is in line with my concern, but I would happily update this PR to that end.

@davidism davidism added this to the 3.2.0 milestone Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Configurable behavior when translated string interpolation fails.
2 participants