[Python-ideas] Gettext syntax (was Re: Allow "assigning" to ...)

[Terry Reedy]

On 2/11/2015 10:33 PM, Terry Reedy wrote:

> A possible solution would be to give 3.x str a __pos__ or __neg__
> method, so +'python' or -'python' would mean the translation of 'python'
> (the snake).  This would be even *less* intrusive and easier to write
> than _('python').
>
> Since () has equal precedence with . while + and - are lower, we would
> have the following equivalences for mixed expressions with '.':
>
> _(snake.format()) == -snake.format()  # format, then translate
>                 # or -(snake.lower())
> _(snake).format() == (-snake).format()  # translate, then format

The core idea of this proposal is to add a single prefix symbol as an 
alternative to _(...).  Summarizing the alternate proposals:

Zero Piraeus suggests that ~ (.__invert__ (normally bitwise)) would be 
better.  I agree.

M.-A. Lemburg points out that neither of
   label = +'I like' + +'Python'
   label = -'I like' + -'Python'
do not 'read well'.  I do not know how common such concatentions are, 
but I agree that they do not look good.

He then suggests a new string prefix, such as i'Internationalized 
String'.  ('_' could also be used as a prefix.)  The compiler could map 
this to, for instance, sys.i18n('Internationalized String'), where initially
   sys.i18n = lambda s: s
The above code would then become
   label = i'I like' + i'Python'  # or
   label = _'I like' + _'Python'
I like this even better except that it raises the issue of interaction 
with the existing r and b (and u) prefixes.

Ron Adam suggests a str._ property, leading to
   label = 'I like'._ + 'Python'._
I prefer 1 char to 2.  On the other hand, a 'suffix' makes a certain 
sense for indicating translation.  Current string prefixes affect the 
translation of literal to object. To properly process a string literal 
containing '\'s, for instance, both compilers and people need to know 
whether it is to be interpreted 'raw' or 'cooked'. Both also need to 
know whether to read it as text or bytes.  Translation is an 
afterthought, currently performed later.


Barry Warsaw pointed out that existing tools can go thru a file, written 
in whatever language, and extract literal strings inside _(...).  For 
this, distinctive awkwardness is an advantage.  A new syntax would work 
better if there were a script to translate back to the old.

-- 
Terry Jan Reedy