Opened 7 years ago

Closed 7 years ago

#10891 closed (fixed)

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

Reported by: Stavros Korokithakis Owned by: Marc Garcia
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 Gaynor)

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 Marc Garcia 7 years ago.
Patch to show what the problem is

Download all attachments as: .zip

Change History (10)

comment:1 Changed 7 years ago by Alex Gaynor

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

Please use preview.

comment:2 Changed 7 years ago by Ramiro Morales

Component: UncategorizedInternationalization

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 7 years ago by Marc Garcia

Owner: changed from nobody to Marc Garcia

comment:4 Changed 7 years ago by Marc Garcia

Summary: Blocktrans fails in 1.1b if there are newlines in the textBlocktrans fails in trunk if there are newlines in the text and eol is dos
Triage Stage: UnreviewedAccepted
Version: 1.1-beta-1SVN

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 7 years ago by Marc Garcia

Attachment: 10891_v0.diff added

Patch to show what the problem is

comment:5 Changed 7 years ago by Marc Garcia

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 7 years ago by Marc Garcia

(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 7 years ago by Marc Garcia

Triage Stage: AcceptedFixed on a branch

comment:8 Changed 7 years ago by Marc Garcia

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

comment:9 Changed 7 years ago by Jannis Leidel

Resolution: fixed
Status: newclosed

(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.

Note: See TracTickets for help on using tickets.
Back to Top