On Mon, Oct 25, 2010 at 1:29 AM, Benjamin Wohlwend <piquad...@gmail.com> wrote:
> Hi,
>
> I reported #13617[1] a couple of months ago, and today Justin Bronn
> committed a fix for it. Unfortunately, the fix doesn't solve my issue
> (which I failed to describe correctly in the issue report, so the
> blame is on me) nor does it address a larger problem that I described
> in the ticket with the current l10n handling of numbers:
>
> Django's handling of localization of numbers in templates may result
> in undesired output with some locales. When rendering structured
> content like JavaScript, it generates output that may be syntactically
> or semantically incorrect, e.g.:
>
> var num = {{ 2.5 }};
>
> is rendered as "var num = 2,5;" (note the decimal separator) using the
> locale "de-de".
>
> . AFAIK, there are only two work arounds:
>
> * completely deactivate l10n
> * convert every floating point number to a string in the view layer,
> using a suitable locale
>
> My proposal is to introduce a block tag that temporarily deactivates
> l10n for the enclosed fragment. See the patch I attached to the
> ticket.
>
> Two other tickets (#14181, #14164) are manifestations of this issue.
> Unfortunately, I found them only after writing the patch. I like the
> tags proposed in #14181 better than my `{% noloc %}{{ variable }}{%
> endnoloc %}`. I'll update my patch if that is the general consensus.
>
> Justin said he'd like some more core dev eyes on the patch, since it
> touches a couple of vital code paths in the template system. So here I
> am :)
Responding so that
"localize off" is a much better approach to localize
1) I think there is still a need for a template filter. There's an
analog here with autoescape; there's an autoescape template tag for a
large block of content, but there's also an escape filter to escape a
single variable.
2) activate() isn't a cheap operation; I know I put {% localize "de"
%} as a use case in the ticket, but on reflection, I'm not sure it's
worth the overhead. That said, I'm willing to be convinced otherwise
if there's a lot of demand for this feature.
3) The '_localize' magic variable in the context. It looks to me like
a better solution would be to pass down a 'localize' argument to
render. This is a little more intrusive to the codebase, but it
doesn't have the same code smell to me.
4) 'force' isn't a good description of the argument to date_format()
et al. I'd be inclined to extend the 'localize' argument from point
(2), and use a ternary logic value; True/False, plus None == use the
value of USE_L10N.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
