Code

Opened 5 years ago

Closed 5 years ago

#10891 closed (fixed)

Blocktrans fails in trunk if there are newlines in the text and eol is dos

Reported by: stavros Owned by: garcia_marc
Component: Internationalization Version: master
Severity: Keywords: i18n-fixed
Cc: Triage Stage: Fixed on a branch
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by Alex)

The blocktrans tag silently fails to show the translation if there are newlines in the text to be translated. Only the original text is shown.

{% blocktrans %}
A test.
{% endblocktrans %}

fails.

{% blocktrans %}A test.{% endblocktrans %}

succeeds.

Attachments (1)

10891_v0.diff (544 bytes) - added by garcia_marc 5 years ago.
Patch to show what the problem is

Download all attachments as: .zip

Change History (10)

comment:1 Changed 5 years ago by Alex

  • Description modified (diff)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

Please use preview.

comment:2 Changed 5 years ago by ramiro

  • Component changed from Uncategorized to Internationalization

Something related to this was reported six month ago on django-users: http://groups.google.com/group/django-users/browse_frm/thread/c051bc5d63e14f0/9956309f9177c972?hl=en&lnk=gst#9956309f9177c972

These are my notes (from a draft of a message never sent to that thread):

I've just tested this and found Django is behaving correctly (translated content is rendered when the template is used with a proper i18n/language preference setup/translation).

Multi-line literals inside blocktrans tags are represented in the PO file as multi-line strings that end with the '\n' literal, e.g.:

msgid ""
"First line\n"
"Second line\n"
"Third line, variable content: %(line3text)s\n"
"Fourth line\n" :

it doesn't matter if the original template file containing such string has Unix or DOS line-endings (both styles were tested).

Also tested was converting the PO file to DOS line endings (starting from r8576 we are creating such files with Unix line-endings
irrespective of the platform where the makemessages command is run) before running compilemessages with similar succesful results.

Platforms where tests were performed are Linux and Windows.

Could you please attach a simple example that demonstrates this?.

comment:3 Changed 5 years ago by garcia_marc

  • Owner changed from nobody to garcia_marc

comment:4 Changed 5 years ago by garcia_marc

  • Summary changed from Blocktrans fails in 1.1b if there are newlines in the text to Blocktrans fails in trunk if there are newlines in the text and eol is dos
  • Triage Stage changed from Unreviewed to Accepted
  • Version changed from 1.1-beta-1 to SVN

I could get this error, but just happens when template's eol is dos. \n is correctly added to .po file, but then, it looks like when looking for the translation, string doesn't match, probably it's missing to replace dos eol by unix one.

Changed 5 years ago by garcia_marc

Patch to show what the problem is

comment:5 Changed 5 years ago by garcia_marc

  • Has patch set
  • Needs tests set
  • Patch needs improvement set

I added a patch that proof that the error is when comparing the string to translate, with the one in the catalog. They don't match, because of using different eol.

I don't think that patch is the best way to fix this error, I just added it to show what's failing.

comment:6 Changed 5 years ago by garcia_marc

(In [11429]) [soc2009/i18n] Refs #10891, fixed bug on blocktrans, that skipped translations of texts containing mac or dos end of lines.

comment:7 Changed 5 years ago by garcia_marc

  • Triage Stage changed from Accepted to Fixed on a branch

comment:8 Changed 5 years ago by garcia_marc

  • Keywords i18n-fixed added
  • Needs tests unset
  • Patch needs improvement unset

comment:9 Changed 5 years ago by jezdez

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

(In [11964]) Fixed #7980 - Improved i18n framework to support locale aware formatting (dates and numbers) and form processing.

Thanks to Marc Garcia for working on this during his Google Summer of Code 2009!

Additionally fixes #1061, #2203, #3940, #5526, #6449, #6231, #6693, #6783, #9366 and #10891.

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.