On 8/11/2015 11:16, Eric V. Smith wrote:
> On 08/11/2015 11:09 AM, Alexander Walters wrote:
>> This may seam like a simplistic solution to i18n, but why not just add a
>> method to string objects (assuming we implement f-strings) that just
>> returns the original, unprocessed string. If the string was not an
>> f-string, it just returns self. The gettext module can be modified, I
>> think trivially, to use the method instead of the string directly.
> You need the original string, in order to figure out what it translates
> to. You need the values to replace into that string, evaluated at
> runtime, in the context of where the string appears. And you need to
> know where in the original (or translated) string to put them.
>
> The problem is that there's no way to evaluate the values and, before
> they're substituted in to the string, use a different template string
> with obvious substitution points. This is what PEP 501 is trying to do.
>
> Eric.
I don't understand some of that. We already trust translators with
_('foo {bar}').format(bar=bar) to not mess up the {bar} in the string,
so the that wont change. Is the issue handing the string back to python
to be formatted? Could gettext not make the same AST as an f-string
would, and hand that back to python? If you add a method to strings
that returns the un-f-string-processed version of the string, doesn't
that make all these problems solvable without pep-501?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4