Proposal: i-String literals in Future Version of Python?

[Robin Becker]

In article <m12A9j5-000CxTC at artcom0.artcom-gmbh.de>, Peter Funk
<pf at artcom-gmbh.de> writes
>If someone is going to internationalize an application in Python, 
>the source will become slightly less readable.  
>The following example statements
>        print "This is just an annoying message"
>       b = Tkinter.Button(text="Foo Bar", ...)
>will turn into
>        print _("This is just an annoying message")
>        b = Tkinter.Button(text=_("Foo Bar"), ...) 
>or even more ugly:
>        print gettext("This is just an annoying message")
>        b = Tkinter.Button(text=gettext("Foo Bar"), ...)
>or
>        print i18n("This is just an annoying message")
>        b = Tkinter.Button(text=i18n("Foo Bar"), ...)
>
>Here the *gettext* method (function) has to return a string, which
>is possibly translated into a foreign language.  Since Python already
>knows raw string literals, I thought that it would be nice, if a
>similar notation could be used to mark i18n string literals.
>So that some magic in the python interpreter expands
>       print i"This is just a message"
>into a call to a gettext function internally, if such a function is
>available.  May be there could be a sys.i18n function which could be 
>initially defined as a identity function:
>       def i18n(string):
>               return(string)
>This way preparing applications for i18n would become even easier.
>What do you think?
>
>Regards, Peter

simpler the better. There was a discussion last year about prefix usage
in relation to documentation etc. However isn't  the real problem that
of getting all the strings into a convenient form/place so that they can
be nicely translated into other languages/charsets. I guess you could
always automatically extract these and replace with
german/french/spanish etc etc using a preprocessor.
-- 
Robin Becker