Re: Deprecating the "u" string literal prefix
I'm struggling to see what i-strings would do for i18n that str.format doesn't do better. Serhiy Storchaka [mailto:storchaka@gmail.com] You would not need to repeat yourself. _('{name} costs ${price:.2f}').format(name=name, price=price)
A small price to pay for having a well-defined interface with the translator. Security is one reason: A translator could sneak {password} or {signing_key} into an unrelated string, if those names happen to be present in the namespace. That may not seem like a big issue if you've only ever used gettext/.po-file translation, where the translation is pre-built with the program, but in a more dynamic setting where end-users can supply translations, it's a different story. You could parse the strings and require translations to have the same variables, but that is limiting. E.g. that would mean you couldn't translate 'Welcome, {first_name}' into 'Willkommen, {title} {last_name}' Another reason is that you don't want variable names in your program and translations to have to change in lock-step. E.g. you might change your code to: _('{name} costs ${price:.2f}').format(name=prod.short_name, price=context.convert_to_chosen_currency(price)) without needing to change any translations. regards, Anders
Please try to get an email client which is able to reply in a thread, rather than creating a new thread each time you send an email. You might want to try HyperKitty: https://mail.python.org/archives/list/python-dev@python.org/ Victor Le jeu. 5 déc. 2019 à 10:50, Anders Munch <ajm@flonidan.dk> a écrit :
I'm struggling to see what i-strings would do for i18n that str.format doesn't do better. Serhiy Storchaka [mailto:storchaka@gmail.com] You would not need to repeat yourself. _('{name} costs ${price:.2f}').format(name=name, price=price)
A small price to pay for having a well-defined interface with the translator.
Security is one reason: A translator could sneak {password} or {signing_key} into an unrelated string, if those names happen to be present in the namespace. That may not seem like a big issue if you've only ever used gettext/.po-file translation, where the translation is pre-built with the program, but in a more dynamic setting where end-users can supply translations, it's a different story.
You could parse the strings and require translations to have the same variables, but that is limiting. E.g. that would mean you couldn't translate 'Welcome, {first_name}' into 'Willkommen, {title} {last_name}'
Another reason is that you don't want variable names in your program and translations to have to change in lock-step. E.g. you might change your code to: _('{name} costs ${price:.2f}').format(name=prod.short_name, price=context.convert_to_chosen_currency(price)) without needing to change any translations.
regards, Anders
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A2PDRFFJ... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
participants (2)
-
Anders Munch -
Victor Stinner