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

[Andrew Barnert]

On Aug 11, 2015, at 16:22, Jonathan Slenders <jonathan at slenders.be> wrote:
> 
> Not exactly.
> 
> Take this string for instance:
> f'hello {name}'
> 
> And our FString implementation, very simple:
> 
> class FString(str):
>     def __init__(self, value, **kwargs):
>         super().__init__(value.format(**self.kwargs))
>         self.value = value
>         self.kwargs = kwargs
> 
> What the above f-string should do is create an instance of that class. This is just a compiler detail. A preprocessor step. Like this:
> 
> FString('hello {name}', name=str(name))
> 
> FString is just an str instance, it has the actual interpolated value, but it still contains the original uninterpolated string and all parameters (as strings as well.)

So you want every i18n string to interpolate the string, ignore that, look up the raw string, re-interpolate that, and somehow modify the string to hold the new l10n+interpolated value instead? Besides the performance cost of interpolating every string twice for no reason, and the possibility of irrelevant errors popping up while doing so, it's also impossible given that strings are immutable. (That also means you have to use a __new__ rather than __init__, by the way, but that's just a minor quibble.)

Also, what happens if the translated string uses a variable that the original string didn't? For example, maybe your English string uses {Salutation} and {Last Name}, but your Chinese string has no need for a salutation, and your Icelandic string only uses the first name. People don't do that very often, but that's partly because many i18n systems are too inflexible to handle it. Python's str.format makes it relatively easy to build something that is flexible enough. Nick's proposal and Barry's both are. This one isn't.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150811/8c6d283d/attachment.html>