Re: [PATCH] python-brace-format: support conversion specifier and unnamed arguments

[Bruno Haible]

Hello Terence,

Terence D. Honles wrote:
> This change updates the `python-brace-format` to detect a format string
> using unnamed arguments (supported since Python 2.7 & 3.1), and also
> allows specifying a conversion specifier which was previously overlooked
> in the parser.

Indeed, when the 'python-brace-format' support was added, it was apparently
based on PEP 3101 [1], which does not contain the additions made for Python 3.1
[2]. Thank you for the patch — it will be useful!

However, there is a problem with this unnamed argument syntax and with the
conversion specifiers as well.

GNU gettext needs to balance the ease for programmers with the ease for
translators. Programmers should be doing what they are good at: writing
and refactoring programs, but not restricting or doing translations.
Translators should be doing what they are good at: translating, but
not reading programming language specifications. It is with this
background that we ask programmers to adjust their source code so
that it makes better sense for the translation [3]. Translators can
be expected, when dealing with format strings, to recognize format
string directives and to keep them unchanged or, when argument reordering
is necessary, to move them around. So, a translator can very well
translate
    "{stock} gained {inc}% today and is now at {newvalue}."
with
    "{stock} est à {newvalue} aujourd'hui, après avoir gagné {inc}%."

* Problems of the unnamed arguments syntax for translators:

  Translators need the ability to reorder arguments. ([4] section 7.1.)
  A translator can well translate
    "{0} gained {1}% today and is now at {2}."
  with
    "{0} est à {2} aujourd'hui, après avoir gagné {1}%."

  But when the given string is
    "{} gained {}% today and is now at {}."
  and the translator transforms it to
    "{} est à {} aujourd'hui, après avoir gagné {}%."
  it is wrong (because at runtime the values will be inserted in the
  wrong place), and no tool has the ability to report an error at this
  stage.

  So, IMO, what GNU gettext should do is:
    - Translators should never see a format string with "{}".
    - When a format string with "{}" occurs in the source code,
      the xgettext program should NOT extract it but instead give a
      warning to the programmer, telling him to insert numeric
      or symbolic names for the arguments.
  (Maybe a format string with a single "{}" can be accepted? Not
  sure whether that makes sense.)

* Problems with the conversion specifiers for translators:

  As I understand it,
    "{0!s}" with argument x
  is equivalent to
    "{0}" with argument x.str()
  and similarly for the other conversion specifiers.

  So, these conversion specifiers are actually a piece of code that the
  programmer has chosen to put into the format string.

  In the context of GNU gettext, this is not good because:
    - The translator sees complexity in the msgids that are not his
      business.
    - When the programmer refactors the code and decides to remove the '!s'
      part or introduce a different conversion specifier, the translators
      will see a changed msgid and be prompted to translate it again.
      Which is unnecessary work for the translator.

  So, here too, GNU gettext should better not present this to the translator.
  Instead, xgettext should give a warning and tell the programmer to move
  the conversion outside of the format string.

Do you agree with this? Does it make sense? (You appear to be more of a
Python expert than I am.)

Bruno

[1] https://peps.python.org/pep-3101/
[2] https://docs.python.org/3/library/string.html#format-string-syntax
[3] https://www.gnu.org/software/gettext/manual/html_node/Sources.html
[4] 
https://www.gnu.org/software/gettext/manual/html_node/Language-Implementors.html