[Python-ideas] String interpolation for all literal strings

[Barry Warsaw]

On Aug 06, 2015, at 06:21 PM, Yury Selivanov wrote:

>Anyways, it would be nice if we can make i18n a little bit
>easier and standardized in python.  That would help with
>adding i18n in existing projects, that weren't designed with
>it in mind from start.

Agreed.  I have to say while I like the direction of trying to marry
interpolation and translation, there are a few things about f-strings that
bother me in this context.  We won't know for sure until the PEP is written,
but in brief:

* Interpolation marker syntax.

I've mentioned this before, but the reason why I wrote string.Template and
adopted it for i18n is because $-strings are very familiar to translators,
many of whom aren't even programmers.  $-strings are pretty difficult to mess
up.  Anything with leading and trailing delimiters will cause problems,
especially if there are multiple characters in the delimiters.

(Yes, I know string.Template supports ${foo} but that is a compromise for the
rare cases where disambiguation of where the placeholder ends is needed.
Avoid these if possible in an i18n context.)

* Arbitrary expressions

These just add complexity.  Remember than translators have to copy the
placeholder verbatim into the translated string, so any additional noise will
lead to broken translations, or worse, broken expressions (possibly also
leading to security vulnerabilities or privacy leaks!).  I personally think
arbitrary expressions are overkill and unnecessary for interpolation, but if
they're adopted in the final PEP, I would just urge i18n'ers to avoid them at
all costs.

* Literals only

I've described elsewhere that accepting non-literals is useful in some cases.
If this limitation is adopted, it just means in the few cases where
non-literals are needed, the programmer will have to resort to less convenient
"under-the-hood" calls to get the strings translated.  Maybe that's acceptable.

* Global state

Most command line scripts have a single translation context, i.e. the locale
of the user's environment.  But other applications, e.g. servers, can have
stacks of multiple translation contexts.  As an example, imagine a Mailman
server needing to send two notifications, one to the original poster and
another to the list administrator.  Those notifications are in different
languages.  flufl.i18n actually implements a stack of translations contexts so
you can push the language for the poster, send the notification, then push the
context for the admin and send that notification (yes, these are context
managers).  Then when you're all done, those contexts pop off the stack and
you're left with the default context.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150807/326926ef/attachment.sig>