f-strings are pretty cool, but they are (by nature) not suitable for
i18n: the placeholders are replaced before the gettext functions can see
them.
AFAICS, we have three options for translatable strings:
- "$-strings", using the string.Template class,
as of PEP 292 (.substitute method);
gettext: sh-format
- traditional % processing,
gettext: python-format
- str.format, as of PEP 3101,
gettext: python-brace-format
Wouldn't it be cool to be able to use the new t-strings as well?
(introduced in Python 3.14, PEP 750)
Existing code using
f"We're all out of {cheese}."
could use instead
_(t"We're all out of {cheese}.")
Of course, the gettext functions and methods would need to treat the
string.templatelib.Template input differently.
For msgid lookup, the gettext function would need to know about the
unparsed shape of the template.
It could then check the message catalog (.mo file) for the translation
and create a template from this (unless already cached somehow),
and finally return a translated string, using the interpolations.
Important:
- The order of interpolations can change, as placeholders may occupy
different positions in different languages,
so we'd need to take care of that
- There might even be legitimate changes in the interpolation "values",
e.g. if some plural form introduces a number which is not present in
the singular form
(we might require the singular form to have this number as well,
though, even if it is not reproduced in the translation)
- Safety / security considerations?
The pygettext script would need to be updated to extract "t-strings" in
the same way like ordinary string literals;
same for the GNU xgettext utility (we'd need to tell them).
BTW, I'd love to see the dedented multiline strings
("d-strings", PEP 822) - to be available in conjunction with this;
but they seem to have been rescheduled to Python 3.16 :'( ...
Any thoughts?
Thanks,
Tobias
--
https://mail.python.org/mailman3//lists/python-list.python.org
