A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2002-January/019523.html below:

[Python-Dev] PEP 216 (string interpolation) alternative EvalDict)

PEP 215 (was Re: [Python-Dev] PEP 216 (string interpolation) alternative EvalDict)jepler@inetnebr.com jepler@inetnebr.com
Tue, 15 Jan 2002 22:21:16 -0600
On Tue, Jan 15, 2002 at 02:04:10AM -0500, Barry A. Warsaw wrote:
> [1] I use _() ostensibly to mark translatable strings, but it has a
> side benefit in that it interpolates into the string named variables
> from the locals and globals of the calling context.  It does this by
> using sys._getframe(1) in Python 2.1 and try/except hackery in older
> versions of Python.  I find it quite handy, and admittedly magical,
> but then I'm not suggesting it become a standard Python feature. :)

This caught my eye.

How will programs that use PEP215 for string interpolation be translatable?
All translation systems use some method of identifying the strings in
source code, then permitting mapping from the string identifiers to the
real strings at runtime.  With "gettext", the "string identifier" is
typically the original-language string, and the marker/mapper is spelled
_("string literal").

Given that short introduction, it's obvious how 
	_("hi there, %s") % yourname
works, and why
	_("hi there, %s" % yourname)
doesn't work, but how will I use a similar scheme to translate
	$"hi there, $yourname"
?  Obviously, 
	_($"hi there, $yourname")
won't work, because it's equivalent to the second, non-working translation
example.

Well, I guess we could add _ and $_ strings to Python, right?

grumble-grumble'ly yours,
Jeff



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4