#10449: Bug: HTML accents not escaped out when using newforms
-------------------------------------------+--------------------------------
          Reporter:  tipan                 |         Owner:  nobody           
            Status:  reopened              |     Milestone:                   
         Component:  Internationalization  |       Version:  1.0              
        Resolution:                        |      Keywords:  accents, newforms
             Stage:  Accepted              |     Has_patch:  0                
        Needs_docs:  1                     |   Needs_tests:  1                
Needs_better_patch:  0                     |  
-------------------------------------------+--------------------------------
Changes (by arien):

  * needs_docs:  0 => 1
  * needs_tests:  0 => 1

Comment:

 I'm not sure what I was smoking when I checked this and wrote comment:2,
 but I doubt it was legal...

 I think using HTML entities (or other markup) in a `msgstr` when there are
 none in the `msgid` is begging for trouble.  By doing this you are
 assuming the `msgstr` will be used in a certain type of context when there
 is no assumption for the `msgid`.  (For example, the `msgstr` in the
 report is only suited for HTML, while the `msgid` could be use in the
 subject of an email.)

 That said, it turns out that Django doesn't mark all translated strings as
 "safe".  In `django.utils.translation.trans_real`, `do_translate` will
 only mark the translation as "safe" if the string to be translated was
 "safe", and `do_ntranslate` will never mark the translation as "safe".
 The inconsistency between these two should be fixed.

 Solving this at the widget level seems wrong to me.  The widgets don't
 know if the data is "safe" or not, it could come from anywhere.  (The
 `choices` for a `Select` widget may come from the `queryset` of a
 `ModelChoiceField`, for example.)  It would also result in inconsistency
 in the auto escaping behaviour of different widgets.  Seems to me, the
 original coder was ''onto'' somehting, not ''on'' somehting...  :-)

 That leaves the question if all translation functions should return "safe"
 strings all the time, or not.  I'm not sure they should.  For the
 `*gettext_lazy` functions it might make sense to always return "safe"
 strings, but I don't think it does for the `*gettext` versions.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/10449#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to