Hi, I posted this before but I think people had the 1.3 release on the brain, so now that's out (congrats :)), I'm trying again:
http://thread.gmane.org/gmane.comp.python.django.devel/30752 ** copied content ** #2594 is now ready for checkin as far as I can tell for the 1.4 milestone (I understand 1.3 is closed), with one side-issue. http://code.djangoproject.com/ticket/2594 The side issue is that msgids in the .po file extracted with makemessages will not match the untranslated string that Django calls gettext with in the case where a blocktrans tag is used like this: <pre> {% blocktrans %} Something {% endblocktrans %} </pre> It seems that makemessages could create a msgid with '\n Something\n ', and the blocktrans tag would try to retrieve the msgid: '\n Something', ie, no 'trailing' whitespace from the line that {% endblocktrans %} is on, if the settings when creating messages does not match the in-production settings. This issue may be solved by http://code.djangoproject.com/ticket/5849 but it's hard to tell because Malcolm Tredinnick didn't cover this particular issue in the mailing list thread and I'm not sure it was considered. So the DDN is one of the following options I think (brainstorming): 0) Ignore the issue. State that makemessages must be run with the same settings as the production site. 1) Patch /django/utils/translation/trans_real.py to strip the last line if it is only whitespace and a blocktrans tag is being processed. Then the #2594 patch can be committed. Affected msgids might have to be retranslated or have a fuzzy marker removed. When looking up the msgid for a blocktrans, try first with the given input, then if that fails, try again with the last line stripped if it is space. That way it would work with and without the whitespace trimming setting. The patch might look something like this (untested, just for illustration): diff --git a/django/utils/translation/trans_real.py b/django/utils/translation/trans_real.py index a5c612b..2a7dfe8 100644 --- a/django/utils/translation/trans_real.py +++ b/django/utils/translation/trans_real.py @@ -272,6 +272,18 @@ def do_translate(message, translation_function): from django.conf import settings _default = translation(settings.LANGUAGE_CODE) result = getattr(_default, translation_function)(eol_message) + if not result: + try_again = False + counter = 0 + for char in eol_message[::-1]: + if not char.isspace(): + break + counter += 1 + if char == '\n': + try_again = True + break + if try_again: + return do_translate(eol_message[:-counter], translation_function) if isinstance(message, SafeData): return mark_safe(result) return result @@ -421,6 +433,12 @@ endblock_re = re.compile(r"""^\s*endblocktrans$""") plural_re = re.compile(r"""^\s*plural$""") constant_re = re.compile(r"""_\(((?:".*?")|(?:'.*?'))\)""") +def join_with_trimmed_trailing_newline(lines): + result = ''.join(lines[:-1]) + if not lines[-1].isspace(): + result += lines[-1] + return result + def templatize(src, origin=None): """ Turns a Django template into something that is understood by xgettext. It @@ -449,13 +467,16 @@ def templatize(src, origin=None): pluralmatch = plural_re.match(t.contents) if endbmatch: if inplural: - out.write(' ngettext(%r,%r,count) ' % (''.join(singular), ''.join(plural))) + S = join_with_trimmed_trailing_newline(singular) + P = join_with_trimmed_trailing_newline(plural) + out.write(' ngettext(%r,%r,count) ' % (S, P)) for part in singular: out.write(blankout(part, 'S')) for part in plural: out.write(blankout(part, 'P')) else: - out.write(' gettext(%r) ' % ''.join(singular)) + S = join_with_trimmed_trailing_newline(singular) + out.write(' gettext(%r) ' % S) for part in singular: out.write(blankout(part, 'S')) intrans = False 2) Solve #5849, thereby making it a blocking issue for #2594, but making the msgid issue described above an issue for #5849. That means the #2594 patch can't be committed until #5849 is resolved. Depending on the resolution of #5894, there may be some effect on existing msgids. 3) Close #2594 and #5894 as WONTFIX. I don't expect (0) is acceptable, (1) is my favorite, (2) might be workable depending on how this issue is resolved in #5849 and (3) gets my -1 because #2594 makes this so much nicer when doing code generation for example. All the best, Steve. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
