bugGNU 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: 


> xgettext should not accept f-strings as arguments ... but should recognise gettext(), or whatever is defined, inside f-strings.


Oh I see. You expressed yourself well; I misunderstood it.

That makes perfect sense.

Bruno Haible <haible>
Project Administrator
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:
'...%(ident)d...' % { 'ident': value }
'...{ident}...'.format(ident=value)

Bruno Haible <haible>
Project Administrator
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>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by haible (Posted a comment)
  • -email is unavailable- added by qtclyinh (Submitted the item)
  •  

    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.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-07 haible StatusNot a Bug None
        Open/ClosedClosed Open
    2021-12-07 haible StatusNone Not a Bug
        Assigned toNone haible
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.11