Code

Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#7027 closed (fixed)

Translating string constans passed to template tags breaks if the string contains spaces

Reported by: Konstantinos Metaxas <kmetaxas@…> Owned by: jacob
Component: Internationalization Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Hi. The documentation for i18n states that the following can be used to translate string constants passed to template tags:

{% some_special_tag _("Page not found") value|yesno:_("yes,no") %}

However, when i use it with a string that contains spaces (like in the example in the docs) it raises a TemplateSyntaxError claiming that more parameters where passed to the some_special_tag than it accepts.

It seems that django.utils.text.smart_split breaks up quoted strings that are enclosed like thus: _("my quoted string") and contain spaces.
Example:

>>> from django.utils.text import smart_split
>>> list(smart_split(' _("my quoted string") '))
[u'_("my', u'quoted', u'string")']
#Without spaces
>>> list(smart_split(' _("myquotedstring") '))
[u'_("myquotedstring")']

This makes translating multi-word string constants in template tags impossible.
I am using svn revision 7425.

Attachments (4)

fix_tag_translation.diff (3.1 KB) - added by mrts 6 years ago.
fix_tag_translation-refactored-re_7027.diff (4.5 KB) - added by mrts 6 years ago.
Refactored the regex and wrote an explanation
fix_tag_translation-refactored-re-strict_gettext_matching_7027.diff (4.5 KB) - added by mrts 6 years ago.
This one won't let " ") and \(" " through, IMHO not worth the extra complexity though
fix_tag_translation-refactored-re-allow_empty_strings-7027.diff (4.5 KB) - added by mrts 6 years ago.
Allow '' and ""

Download all attachments as: .zip

Change History (19)

comment:1 Changed 6 years ago by mtredinnick

  • Component changed from Template system to Internationalization
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 6 years ago by mrts

  • Has patch set
  • milestone set to 1.0

This clearly a bug that needs to fixed before 1.0. Attaching a patch with fixes and tests.

Changed 6 years ago by mrts

comment:3 Changed 6 years ago by mrts

Just a note that the patch passes all tests.

comment:4 Changed 6 years ago by jacob

Goddamn that regex is scary. mrts, think you can rewrite it to use re.X and add some comments so we know what's going on there?

comment:5 Changed 6 years ago by mrts

Will do it shortly.

comment:6 Changed 6 years ago by mrts

But note that basically I just circumfixed non-grouping matches for either _('') or _("") and used raw strings to lessen the wild escaping in the original.

comment:7 Changed 6 years ago by mrts

Now that I review it, it looks like the original pattern (not written by me and carried over in this patch) is too complex. I should have cut it more radically. The proliferation of \ had a bad smell but I kind of assumed the person knew what he was doing. Jacob, do you know who it was so that I can discuss this with him? I see a much more straightforward pattern, but perhaps I'm missing something.

comment:8 Changed 6 years ago by mtredinnick

Just upload a new patch. We'll work out if it's good enough. But, really, at this point, the smallest possible change that gets the job done is the only correct approach. Larger changes contain more bugs.

Changed 6 years ago by mrts

Refactored the regex and wrote an explanation

comment:9 Changed 6 years ago by mrts

Just a note -- this passes all tests.

Changed 6 years ago by mrts

This one won't let " ") and \(" " through, IMHO not worth the extra complexity though

comment:10 Changed 6 years ago by anonymous

This one won't let " ") and \(" " through, IMHO not worth the extra complexity though -- entirely pointless. Group C (see comments) will match unclosed bits anyway, so the last patch isn't really useful, there's no difference between _("foo and _("foo bar" correctness-wise -- both are invalid. Thus, fix_tag_translation-refactored-re_7027.diff is the way to go.

comment:11 Changed 6 years ago by mrts

And here are some illustrations for the invalid cases:

# with fix_tag_translation-refactored-re-strict_gettext_matching_7027.diff
>>> list(smart_split("_('foo bar'"))
[u"_('foo", u"bar'"]
>>> list(smart_split("_('foo bar"))
[u"_('foo", u'bar']
>>> list(smart_split("'foo bar"))
[u"'foo", u'bar']

# with fix_tag_translation-refactored-re_7027.diff -- best behaviour
>>> list(smart_split("_('foo bar'"))
[u"_('foo bar'"]
>>> list(smart_split("_('foo bar"))
[u"_('foo", u'bar']
>>> list(smart_split("'foo bar"))
[u"'foo", u'bar']

# original 
>>> list(smart_split("_('foo bar'"))
[u"_('foo", u"bar'"]
>>> list(smart_split("_('foo bar"))
[u"_('foo", u'bar']
>>> list(smart_split("'foo bar"))
[u"'foo", u'bar']

comment:12 Changed 6 years ago by mrts

An afterthought: the regex should allow empty strings, so (?:[^"\\]|\\.)+ should be (?:[^"\\]|\\.)* instead.

Changed 6 years ago by mrts

Allow '' and ""

comment:13 Changed 6 years ago by jacob

  • Owner changed from nobody to jacob
  • Status changed from new to assigned

After thinking this through a bit more, doing this is smart_split isn't a good idea: smart_split shouldn't have to have any idea about translation-marked strings. I think the right place to this is in template.Token.split_contents, so I'll have a whack at doing it there.

comment:14 Changed 6 years ago by jacob

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [8769]) Fixed #7027: template tags now corectly break tokens around strings marked for translation.

comment:15 Changed 3 years ago by jacob

  • milestone 1.0 deleted

Milestone 1.0 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.