GNU gettext - Bugs: bug #61596, Support for Python f-strings
You are not allowed to post comments on this tracker with your current authentication level.
bug #61596: Support for Python f-strings
Submitter: | Ben <qtclyinh> | ||
Submitted: | Wed 01 Dec 2021 04:02:14 PM UTC | ||
Category: | Python | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | haible |
Open/Closed: | Open |
Tue 07 Dec 2021 10:12:27 PM UTC, comment #4: |
Bruno Haible <haible>![]() ![]() |
Tue 07 Dec 2021 06:10:58 PM UTC, comment #3: I am afraid I did not express myself well: xgettext should not accept f-strings as arguments of () or gettext(), but should recognise () or gettext(), or whatever is defined, inside f-strings.
So, in the last example:
f'<label>{self._("Title")}:</label>'
xgettext should recognise "Title", because of _() inside the f-string.
So, what xgettext should do is evaluate anything inside braces {} within f-strings as normal Python (which it is!) to see whether there are any gettext() calls.
An f-string is any Python string (with ', ", ''' or """) prepended by an 'f' or an 'F'. |
Ben <qtclyinh> |
Tue 07 Dec 2021 04:41:07 PM UTC, comment #2: Supporting this kind of strings in xgettext in the naïve way, i.e. where the string itself would appear as an msgid in the PO file, is not appropriate for the following reasons:
1) PEP 498 says "It should be noted that an f-string is really an expression evaluated at run time". But the translator is not a programmer. An expression from a programming language is just gibberish to a translator; we should not expose translators to that.
2) The translator would have the ability to change the expressions that occur inside an f-string. (Even if 'msgfmt -c' checks against that; some tool don't invoke msgfmt with the '-c' option.) To make this safe, the verification that the expressions have not been modified during translation would have to occur at runtime.
3) When the programmer changes the subexpressions, this would lead to a modified POT file, and work for the translators ensues.
It would be possible to write into the POT file a derived string, e.g. in your example '<label>{0}:</label>'. But then we need a runtime function that substitutes expression values into a format string that comes from a translator. Still, the added complexity feels awkward. It is better to let the programmer change their program, to separate internationalization and formatting, so that it uses one of the two supported format string syntaxes:
|
Bruno Haible <haible>![]() ![]() |
Wed 01 Dec 2021 04:04:48 PM UTC, comment #1: Sorry, the last example should read:
f"""<label>{self._("Title")}:</label>"""
or:
f'<label>{self._("Title")}:</label>' |
Ben <qtclyinh> |
Wed 01 Dec 2021 04:02:14 PM UTC, original submission:
Python 3.5 introduced f-strings, as specified in PEP 498 Literal String Interpolation:
https://www.python.org/dev/peps/pep-0498/
Basically it means that if a string is prefixed with the letter f (uppercase or lowercase), inside the string there can be any Python expression within braces, such as:
f'My name is {name}!' # Inserts the value of variable name.
f"My name is {sanitise(name)}!"
f'''<label>{gettext("Title")}:</label>'''
f'<label>{self._("Title")}:</label>"""
Currently, xgettext does not recognise gettext() calls inside f-strings. |
Ben <qtclyinh> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Oh I see. You expressed yourself well; I misunderstood it.
That makes perfect sense.