[Python-Dev] The "i" string-prefix: I18n'ed strings

[Alex Martelli]

On 4/6/06, Martin Blais <blais at furius.ca> wrote:
   ...
> So I had the following idea: would it not be nice if there existed a
> string-prefix 'i' -- a string prefix like for the raw (r'...') and
> unicode (u'...') strings -- that would mark the string as being for
> i18n?   Something like this (reusing my example above)::

+1: having helped out with substantial amounts of i18n work over the
years, I agree with you 100% that this addition would give substantial
benefits.

> - We could also have a prefix "I" for strings to be marked but not
> runtime-translated, to replace the N_() strings.

I'm more dubious about this one, because I don't really see the point.
 Expand pls?  With a couple of use cases, maybe?

> - My impression is that this process of i18n is common enough that it
> does not "move" very much, and that there aren't 18 ways to go about
> it either, so that it would be reasonable to consider adding it to the
> language.   This may be completely wrong, I am by no means an i18n
> expert, please show if this is not the case.

My experience agrees with your assessment regarding the first half of
the proposal (but I don't get the second half, I think).

> Okay, let's push it further a bit:  how about if there was some kind
> of generic mechanism built-in in Python for adding new string-prefixes
> which invoke callbacks when the string with the prefix is evaluated?

I think this one is an idea for Python 3000: you should probably post
it to that mailing list.

> This could be used to implement what I'm suggesting above, and beyond.
>  Something like this::
>
>    import i18n
>    i18n.register_string_prefix('i', _)
>    i18n.register_string_prefix('I', N_)
>
> I'm not sure what else we might be able to do with this, you may have
> other useful ideas.

Oh, plenty of things, such as d'123.45' as a syntax for "decimal
literals" (or viceversa for binary floats, if decimals become the Py3k
default), q'123/54' for rationals (today's gmpy.mpq('123/54') or other
implementations), etc.  Ideas which have little to do with i18n,
mostly. It's exactly because of the broad impact of such a mechanism
(and, inevitably, the possibility of abuse and overuse) that I think
it's Py3k material, not 2.* stuff.


Alex