Crutcher Dunnavant wrote:
> Well, what if we added '%{expression}s' as a formating type?
> This would make your example:
>
> print _("%{user}s is not a member of the %{listname}s mailing list")
>
> or even:
>
> print _("%{utils.websafe(form.get('user'))}s is not a member of the
> %{mlist.get_name()}s mailing list")
I don't think evaluation should be allowed except with syntactic
support. So $"%{expression}s" is safe, because it is a string literal
that the programmer specifically wanted substituted.
_("%{expression}s") is less safe, because _() doesn't know where that
string came from, and maybe it came from an unsafe source (like a web
form submission). And _() is also less safe, because it is not obvious
that it looks in the calling frame for information. Even what Mailman
does is potentially slightly unsafe if they were to accept input to _()
from untrusted sources, though exploiting str() is rather hard, and
Mailman presumably has at least a moderate amoung of trust for translators.
It's not actually unreasonable that translation strings could contain
expressions, though it's unlikely that Python expressions are really
called for. Like with pluralization: "Displaying $count ${'user' if
count==1 else 'users'}" is reasonable, though a more constrained syntax
would probably be more usable for the translators. It seems there's a
continuum of use cases.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
