You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This particular alias value is also commonly used as a placeholder for ignored unpacked values (tuples) and other scenarios (e.g., loop variables) which can produce runtime conflicts when co-existing in the same method with translatable text - as was the case with #422.
We should replace the "custom alias" of _ = trans.gettext with something that is both more clear and less intrusive. I propose we update the alias to: _i18n = trans.gettext since i18n is an extremely common abbreviation for text localization (l10n is used as well, but less common). This way, translatable messages can be easily identified and co-exist in methods with the more common use of _.
This would result in the problematic method in #421 to look more like the following...
Came here to report the same bug in launch_browser() (which I see is already fixed). However, _ is also the recommended alias for gettext in the Python documentation, which honestly seems like a very curious suggestion given its other common usage for throwaway variables. See also this StackOverflow question that warns against this exact scenario.
I agree with you, though; changing the i18n alias to something more explicit would prevent this from happening again.
Currently, the translation function
trans.gettext
is aliased to_
intransutils.py
and imported into modules that use it.This particular alias value is also commonly used as a placeholder for ignored unpacked values (tuples) and other scenarios (e.g., loop variables) which can produce runtime conflicts when co-existing in the same method with translatable text - as was the case with #422.
We should replace the "custom alias" of
_ = trans.gettext
with something that is both more clear and less intrusive. I propose we update the alias to:_i18n = trans.gettext
sincei18n
is an extremely common abbreviation for text localization (l10n
is used as well, but less common). This way, translatable messages can be easily identified and co-exist in methods with the more common use of_
.This would result in the problematic method in #421 to look more like the following...
The text was updated successfully, but these errors were encountered: