[Python-ideas] Fix the DRY problem (was Re: PEP 501 - i18n with marked strings)

[Barry Warsaw]

On Aug 14, 2015, at 10:32 PM, Eric V. Smith wrote:

>One thing that concerns me about gettext integration is the tooling
>support.

That worries me about PEP 498 too, but for different reasons.  See my other
follow up (in python-dev I think).

>For example, could pygettext be taught about f-strings, and could it be made
>to handle cases such as the 3rd example in:
>https://docs.python.org/3/library/gettext.html#deferred-translations ?
>
>That is: some f-strings in a module that are i18n-aware, and some that
>aren't. If the "built in" nature of f-strings mean that the tooling can't
>detect all of the desired use cases, should we move forward with an
>i18n-friendly version of f-strings? I'm concerned about designing a lot of
>plumbing for i18n, but no one will end up using because it can't do quite
>enough.

That's a great question.  It could be solved by having a prefix explicitly for
i18n extraction, e.g. PEP 501's i-strings.  I agree that mixing translatable
strings with strings-not-to-be-translated is an issue worth figuring out
because you don't want to overload translators with a bunch of string they
don't have to translate.

As for deferred translations, they are rare enough that some alternative
spelling is IMHO acceptable.

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/20150817/1c08241c/attachment.sig>