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?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
