Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
>> I'd suggest using parso to do it. It's a really great library to write such >> transformations. > > Ah. It wasn't clear what your destination was, so I thought you were > talking about doing the translation itself using parso. But yeah, grab > one of these sorts of parsing libraries, do the transformation, save > back, then use a standard translation library. Seems a lot easier than > changing the language. Ah, my bad. I agree that this is the way forward for people who are trying to localize an existing app, but I still think we should _also_ change the language. F-strings are great and .format is powerful but there is a too big gap in usability and readability between them. This gap is one of the most compelling motivations for my suggestion of a short form for keyword arguments, while also helping us poor guys who deal with huge legacy code bases :) / Anders___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
On Wed, Sep 19, 2018 at 4:52 PM Anders Hovmöller wrote:
>
>
> > How about this: Have a script that runs over your code, looking for
> > "translatable f-strings":
> >
> > _(f'Hi {user}')
> >
> > and replaces them with actually-translatable strings:
> >
> > _('Hi %s') % (user,)
> > _('Hi {user}').format(user=user)
> >
> > Take your pick of which way you want to spell it. Either of these is
> > easily able to be picked up by a standard translation package, is 100%
> > legal Python code in today's interpreters, and doesn't require any
> > bizarre markers and such saying that things need to be processed out
> > of order (the parentheses specify the order for you).
>
>
> I guess it wasn't clear before.. that's exactly what I was proposing :)
>
> I'd suggest using parso to do it. It's a really great library to write such
> transformations.
Ah. It wasn't clear what your destination was, so I thought you were
talking about doing the translation itself using parso. But yeah, grab
one of these sorts of parsing libraries, do the transformation, save
back, then use a standard translation library. Seems a lot easier than
changing the language.
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
> How about this: Have a script that runs over your code, looking for
> "translatable f-strings":
>
> _(f'Hi {user}')
>
> and replaces them with actually-translatable strings:
>
> _('Hi %s') % (user,)
> _('Hi {user}').format(user=user)
>
> Take your pick of which way you want to spell it. Either of these is
> easily able to be picked up by a standard translation package, is 100%
> legal Python code in today's interpreters, and doesn't require any
> bizarre markers and such saying that things need to be processed out
> of order (the parentheses specify the order for you).
I guess it wasn't clear before.. that's exactly what I was proposing :)
I'd suggest using parso to do it. It's a really great library to write such
transformations.
/ Anders
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
On Wed, Sep 19, 2018 at 3:55 PM Steve Barnes wrote:
> Surely the simpler solution is to specify in I18n any items within
> un-escaped {} pairs is excluded from the translation, lookups, etc., and
> that translation needs to take place, also leaving the {} content alone,
> before f string processing. Other than that there is no change. So:
>
> _(f'Hi {user}') would be in the .po/.mo as just 'Hi ' and if our locale
> is set to FR this gets translated to f'Bonjor {user}' which then gets
> the user variable substituted in.
How about this: Have a script that runs over your code, looking for
"translatable f-strings":
_(f'Hi {user}')
and replaces them with actually-translatable strings:
_('Hi %s') % (user,)
_('Hi {user}').format(user=user)
Take your pick of which way you want to spell it. Either of these is
easily able to be picked up by a standard translation package, is 100%
legal Python code in today's interpreters, and doesn't require any
bizarre markers and such saying that things need to be processed out
of order (the parentheses specify the order for you).
Not everything has to be an f-string.
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
On 18/09/2018 08:59, Hans Polak wrote:
>
>>> I don't see how this immediately helps the OP, who wants a *literal*
>>> expression that automatically invokes the translation machinery as
>>> well as the interpolation machinery.
> Actually, no, I do not want the expression to be automatically
> translated at compile time. It should be translated at run-time. There
> are three situations.
>
> 1. No translation, just a regular f-string.
> 2. App translation. The f-string gets translated to the configured
> language.
> 3. On the fly translation. The string gets translated to the language
> passed as an argument as required.
>
> In code, this would be.
> 1. f'Hi {user}'
> 2. f'{!g}Hi {user}'
> 3. f'{lang!g}Hi {user}'
>
> Cases 2 and 3 need some additional code, just like with gettext.
>
> I'm sorry if that wasn't clear from the start. All I want is the code to
> be simpler to write and maintain. I do not want to have complicated
> parsing for the compiler.
>
>>> Another way forward could be a preprocessor. All this can be done
>>> with a fairly simple script using parso.
> This is probably the idea.
>
> Cheers,
> Hans
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
Surely the simpler solution is to specify in I18n any items within
un-escaped {} pairs is excluded from the translation, lookups, etc., and
that translation needs to take place, also leaving the {} content alone,
before f string processing. Other than that there is no change. So:
_(f'Hi {user}') would be in the .po/.mo as just 'Hi ' and if our locale
is set to FR this gets translated to f'Bonjor {user}' which then gets
the user variable substituted in.
If you wanted to insert into an f string a value that is itself subject
to I18n you need to mark the content assigned to that value for
translation. For example:
parts_of_day = [_("Morning"), _("Afternoon"), _("Evening"), _("Night"), ]
tod = lookup_time_as_pod()
greeting = _(f"Good {tod}")
If our locale happens to be a German one and our current time of day is
morning then tod will be assigned as "morgan" and our greeting will be
"Gutten Morgan", etc.
This should work without any major problems whether our locale is fixed
at start-up or changes dynamically.
As far as I can see the only possibly required change to the core python
language is that the evaluation order may need to be able to be
override-able so that the translate function, (with the leave {.*} alone
rule), is called _before_ the f string formatting, (I think that with
current precedence it would not). Is there, or could there be, an
"@eager" or "@push_precedence" decorator, or some such, that could be
added to translate so as to do this? The remaining changes would be in
the translate/I18n package(s) and the documents of course.
--
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.
---
This email has been checked for viruses by AVG.
https://www.avg.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
I don't see how this immediately helps the OP, who wants a *literal*
expression that automatically invokes the translation machinery as
well as the interpolation machinery.
Actually, no, I do not want the expression to be automatically
translated at compile time. It should be translated at run-time. There
are three situations.
1. No translation, just a regular f-string.
2. App translation. The f-string gets translated to the configured language.
3. On the fly translation. The string gets translated to the language
passed as an argument as required.
In code, this would be.
1. f'Hi {user}'
2. f'{!g}Hi {user}'
3. f'{lang!g}Hi {user}'
Cases 2 and 3 need some additional code, just like with gettext.
I'm sorry if that wasn't clear from the start. All I want is the code to
be simpler to write and maintain. I do not want to have complicated
parsing for the compiler.
Another way forward could be a preprocessor. All this can be done with a fairly
simple script using parso.
This is probably the idea.
Cheers,
Hans
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
>> See also PEP 501, which could be used for i18n. > > I don't see how this immediately helps the OP, who wants a *literal* > expression that automatically invokes the translation machinery as > well as the interpolation machinery. Another way forward could be a preprocessor. All this can be done with a fairly simple script using parso. If the op is interested I could whip out a prototype. The cool thing about parso is that it’s a round trip AST so it’s easy to perform refactorings or in this case preprocessing without affecting formatting or comments. / Anders ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Combine f-strings with i18n - How about using PEP 501?
Eric V. Smith writes: > See also PEP 501, which could be used for i18n. I don't see how this immediately helps the OP, who wants a *literal* expression that automatically invokes the translation machinery as well as the interpolation machinery. The translation machinery needs access to the raw template string, which is what (human) translators will be provided by pygettext. But as far as I can see there is nothing in i-string processing that provides a hook for this. It presumably wouldn't be impossible to provide a class or factory function derived from InterpolationTemplate that transparently does the lookup, and then constructs an InterpolationTemplate (duplicating the compiler's work?) But a direct compilation to InterpolationTemplate is hard-wired for (literal) i-strings. AFAICS this is the *only* benefit of PEP 501 over simply defining the InterpolationTemplate class in a library module, and it's not usable by gettext-style I18N! We could add a `translate` method, to completely replace the raw_template *before* the compiler parses it into parsed_template. But this gets complicated in the sense of the Zen, because we want to be able to change the translate method on the fly (if the target language changes, or to change the gettext domain, or whatever), or if we have non-I18N uses for i-strings in our application. I hope I'm missing something! Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
