Re: Best-practice for formatted string literals and localization?

2020-12-07 Thread Hartmut Goebel
Am 01.12.20 um 19:40 schrieb Dieter Maurer: Usually, the translation machinery has special ways to provide parameters for translations. For example with `zope.i18nmessageid`, you can use `_(msg, mapping=)` to provide parameters to the translations -- as in your case `count`). Check, what

Re: Best-practice for formatted string literals and localization?

2020-12-07 Thread Hartmut Goebel
Am 30.11.20 um 19:58 schrieb Chris Angelico: Not really, no. Thanks for confirming my apprehension. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | --

Re: Best-practice for formatted string literals and localization?

2020-12-01 Thread Dieter Maurer
Hartmut Goebel wrote at 2020-11-30 19:30 +0100: >formatted string literals are great, but can't be used together with >localization: > >_(f"These are {count} stones") > >will crash babel ("NameError: name 'count' is not defined". Translations are kept in external files (without any runtime

Re: Best-practice for formatted string literals and localization?

2020-11-30 Thread Chris Angelico
On Tue, Dec 1, 2020 at 5:31 AM Hartmut Goebel wrote: > > Hi, > > formatted string literals are great, but can't be used together with > localization: > > _(f"These are {count} stones") > > will crash babel ("NameError: name 'count' is not defined". And even it > it would succeed, the

Best-practice for formatted string literals and localization?

2020-11-30 Thread Hartmut Goebel
Hi, formatted string literals are great, but can't be used together with localization: _(f"These are {count} stones") will crash babel ("NameError: name 'count' is not defined". And even it it would succeed, the *evaluated* string would be passed to "_(…)", resulting in a not-translated