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