
Barry Warsaw writes:
Besides, any expression you have to calculate can go in a local that will get interpolated.
Sure, but that style should be an application programmer choice. If this syntax can't replace the vast majority of cases where the format method is invoked on a literal string without requiring introduction of gratuitous temporaries, I don't see the point. By "invoked", I mean the arguments to the format method, too, so even function calls should be permitted. To me it's not worth the expense of learning and teaching the differences otherwise. If that point of view were generally accepted, it seems to me that it kills this idea of using the same syntax for programmer interpolation and for translation interpolation. The two use cases present requirements that are too different since translators are generally "third party volunteers", *not* "trusted contributors". Nor are their contributions generally reviewed by "core".
In an i18n context, you want to stick to the simplest possible substitution placeholders.
Certainly, and in that case I think format strings with simple variable and attribute interpolation, plus an explicit invocation of the format method comprise TOOWDTI -- it's exactly what you want! In fact, I am now -1 on an implicitly formatted I18N quasi-literal. It seems to me that in fact we should think of such an internationalized string as merely an obfuscated way of spelling variable_input_by_user. The current I18N frameworks make this clear by requiring a function call, which theoretically could return any string and have any side effects -- but these are controlled by the programmer. But there are other contexts, equally important, where a more compact, implicit formatting syntax would be very valuable, starting with scripting. BTW, I know application programmers hate those calls. I wonder if they can't be folded into str.format, with a dummy string prefix of "i" (or "_"!) being allowed solely to trigger xgettext and similar potfile extraction utilities? So you'd write
s = i"Please translate this {adjective} string." s.format(adjective=i"beautiful", gettext=('ja', None)) "この美しい文字列を訳してくださいませ。"
where the first component of gettext is the language and the second is the gettext domain (defaulting to the current application). If that works, the transformation from monolingual application to internationalized application is sufficiently mechanical that a non- programmer could be easily taught to perform it.