On 4/6/06, Martin Blais <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
