Home Original page

[Python-ideas] Fix the DRY problem (was Re: PEP 501

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

Eric V. Smith eric at trueblade.com
Sat Aug 15 04:32:37 CEST 2015 
On Aug 14, 2015, at 11:00 AM, Barry Warsaw <barry at python.org> wrote:
> 
>> On Aug 14, 2015, at 09:05 AM, Eric V. Smith wrote:
>> 
>>> On 08/13/2015 10:00 AM, Barry Warsaw wrote:
>>> Is there a problem with keeping the named placeholders throughout
>>> the entire stack?
>> 
>> I guess not. It complicates things in the non-translated case, but I
>> think it's probably all workable. I'll give it some thought.
> 
> Thanks.
> 
>> But is that enough? I'm not exactly sure what goal we're trying to
>> achieve here. If it's to entirely replace the gettext module,
>> including things like ngettext, then I think it's not an achievable
>> goal, and we should just give up. If it's only to replace
>> gettext.gettext (commonly used as "_"), then I think there's hope.
> 
> From my perspective, exactly this.  I don't expect or want to replace
> gettext.  Part of the focus of PEP 501 is to enable gettext as a use case,
> binding it opportunistically to the __interpolate__ built-in.  Without that
> binding, you get "normal" interpolation.

One thing that concerns me about gettext integration is the tooling support. 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.

Eric.
More information about the Python-ideas mailing list