[Python-ideas] PEP 501 - i18n with marked strings

Petr Viktorin encukou at gmail.com
Tue Aug 11 13:23:46 CEST 2015


On Tue, Aug 11, 2015 at 1:14 PM, Ned Batchelder <ned at nedbatchelder.com> wrote:
> On 8/11/15 6:50 AM, Petr Viktorin wrote:
>>
>> On Tue, Aug 11, 2015 at 12:43 PM, Ned Batchelder <ned at nedbatchelder.com>
>> wrote:
>>>
>>> On 8/10/15 4:31 PM, Mike Miller wrote:
>>>>
>>>> Hi,
>>>>
>>>> I haven't done i18n recently, so bare with me.  I'm not sure about
>>>> bolting
>>>> this on to "format strings", in that it feels like an orthogonal
>>>> concept.
>>>>
>>>> However, what if we had i18n strings as well, not instead of:
>>>>
>>>>      i'Hello there, $name {age}.'
>>>>
>>> You haven't said what this would *mean*, precisely.  I18n tends to get
>>> very
>>> involved, and is often specific to the larger framework that you are
>>> using.
>>> Most people have adopted conventions that mean the syntax is already
>>> quite
>>> simple for strings to be localized:
>>>
>>>      _("Hello there, {name}").format(name=name)
>>>
>>> What would i"" bring to the table?
>>
>> Not having to repeat the variable name three times.
>
> That's what f"" does.  I don't understand what i"" adds to it.


Well, if you want to get the equivalent of:

    _("Hello there, {name}").format(name=name)

you can't use:

    _(f"Hello there, {name}")

because then the `_` function would get the substituted string. The
translation database only contains "Hello there, {name}", not "Hello
there, Ned"; you need to pass the former to `_`.
In other words, if f was a function instead of a prefix, you want to
call f(_("string")), not _(f("string")).

The i"" would allow specifying a translation function, which is
typically custom but project- (or at least module-) global.


More information about the Python-ideas mailing list