[Idle-dev] I18N prep work - convert strings to use format()

[Terry Reedy]

On 1/21/2015 10:51 AM, Tal Einat wrote:
> On Wed, Jan 21, 2015 at 10:03 AM, Al Sweigart <al at inventwithpython.com> wrote:
>>
>> I'd like to change the old-style string formatting from '%s %s' %
>> (foo, bar) to the format() string method version. This is not just a
>> cosmetic change, but would be part of the prep work for I18N support
>> for IDLE.

Since I currently regard internationalizaiton as pie in the sky, I would 
tend to see such changes as cosmetic.  If I were editing format strings 
anyway, I might then make the change simply because I prefer it.

>> For some languages, the order that variables would need to be
>> interpolated into strings would not be the same. For example, in
>> English you could have:
>>
>> color = 'black'
>> animal = 'cat'
>> "The %s %s's toy." % (color, animal)
>>
>> While in Spanish, this would be:
>>
>> color = 'negro'
>> animal = 'gato'
>> "El juguete del %s %s." % (animal, color)

This can also be done with % formats.

 >>> "The %(color)s %(anim)s's toy." % {'color': 'black', 'anim': 'cat'}
"The black cat's toy."
 >>> "El juguete del %(anim)s %(color)s." % {'color': 'negro', 'anim': 
'gato'}
'El juguete del gato negro.'

That said, I prefer .format, and also note that the Idle replacement 
strings (as opposed to the format), should not need translation.

>> However, this defeats translating the "The %s %s's toy." string for
>> I18N. Using the format() string method fixes this: "The {color}
>> {animal}'s toy." could be translated as "El juguete del {animal}
>> {color}."
>>
>> I'd like to go through the strings in IDLE and convert them to use
>> format(). This wouldn't be all of the strings: only those that are
>> user-facing and have multiple %s (or other) conversion specifiers
>> would need to be translated.

The only examples I can think of where this applies are warning messages 
such as

     warning = ('\n Warning: configHandler.py - IdleConf.GetOption -\n'
                ' invalid %r value for configuration option %r\n'
                ' from section %r: %r' %
                 (type, option, section,
                 self.userCfg[configType].Get(section, option,
                               raw=raw)))

If Il8n did happen, these would be a low priority, as Il8n advocates 
have said menu first, then configuration dialogs next.  Unlike exception 
messages, which would not be translated, such messages should hopefully 
never be seen, and in a classroom, an instructor would need to interpret 
it anyway as to what to do.

When I work on confighandler (which definitely needs work) and review 
its warning messages, I should like to revise this one (and others like 
it) to specify the file with the problem, so one would know where to 
make a fix. For this one, the file depends on the user config directory 
and the config type.  (Telling users where the message comes from is 
pretty useless.)  I might rewrite as

warning = ("Config Warning: user configuration file {fname},"
            "section [{sname}], option {oname} must be type {tname}.  "
            "Entry {uval} is not valid; using backup value instead."
             .format(fname=<whatever>, sname=section, oname=option,
              tname=type, uval=...))

>> This is a change that touches on a lot of files, so I wanted to see if
>> anyone could foresee issues with this change before I start on it.

Not useful now in itself.

> If i18n is your goal, are you sure that string.format() is the way to go?

Either kind of format can be translated if one uses field names. If one 
replaces by position, .format is better since one can switch from '{0} 
{1}' to '{1} {0}' without changing the .format call.  With 4 or 5 
fields, as in the real example above, I like field names.  For code that 
should never be run, the run time cost is irrelevant.

-- 
Terry Jan Reedy