Barry A. Warsaw:
> def whereBorn(name):
> country = countryOfOrigin(name)
> return _('$name was born in $country')
> ...
> The feature would be useless to me if I had to pass some explicit
> dictionary into the _() method. It makes writing i18n code extremely
> tedious.
I think you are overstating the problem here. The explicit bindings are a
small increase over your current code as you are already creating an extra
variable just to use the automatic binding. With explicit bindings:
def whereBorn(name):
return _('$name was born in $country',
name=name, country=countryOfOrigin(name))
The protection provided is not just against untrustworthy translaters but
also allows checking the initial language code. You can ensure all the
interpolations are provided with values and all the provided values are
used. It avoids exposing implementation details such as the names of local
variables and can ensure that a more meaningful identifier in the local
context of the string is available to the translator. For example, I may
have some code that processes a command line argument which has multiple
uses on different execution paths:
_('$moduleName already exists', moduleName = arg)
_('$searchString can not be found', searchString = arg)
Not making bindings explicit may mean that translators use other
variables available at the translation point leading to unexpected failures
when internal details are changed.
Neil
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4