[Patch] Better i18n codes

[Jun Omae]

I created the patch for better i18n codes​ for account-manager plugin.

1. Use dgettext() instead of from acct_mgr.api import _ hack in admin_*.html.
2. Replace verification code to verification token in acct_mgr/templates/register.html. All the other phrases are verfication token.
3. Remove href in i18n:msg attribute in reset_password.html. The value is not used.
4. Add i18n:msg attributes to <p py:when="reset.sent_to_email"> in reset_password.html. It's too hard to translate in Japanese.
5. Add %(link)s named-parameter. The separated message makes the translations difficult.

Please apply the patch, if you can.

[Steffen Hoffmann]

Replying to jun66j5:

I created the patch for better i18n codes​ for account-manager plugin.

1. Use dgettext() instead of from acct_mgr.api import _ hack in admin_*.html.

This is a hack, since Genshi seems able to accomplish the message extraction, but later fails on the required runtime translation. This has been discovered first with ScreenshotsPlugin, and the workaround is, what we came up there.

Could you explain your preference for the direct dgettext call? This seems unusual, as we otherwise we try to use the translation utils from Trac as much as we can. If I understand better, I'll do better in future projects and correct same issue in other plugins as well. Thanks in advance for any hint.

![...] Please apply the patch, if you can.

I can. :-) And I will. :-)) Thanks for another profound enhancement request.

[Jun Omae]

Replying to hasienda:

Could you explain your preference for the direct dgettext call? This seems unusual, as we otherwise we try to use the translation utils from Trac as much as we can. If I understand better, I'll do better in future projects and correct same issue in other plugins as well. Thanks in advance for any hint.

I think that the calling dgettext in genshi templates is usual. If it's unusual, Chrome.populate_data() should not set dgettext.

1. ​Chrome.populate_data() sets dgettext by default.
   cf. ​trac:r7705#file2, ​Chrome._default_context_data.
2. babel extracts dgettext keyword. The default keywords includes dgettext.
   cf. ​http://babel.edgewall.org/intertrac/source:branches/stable/0.9.x/babel/messages/extract.py@447:46#L40.

This is a hack, since Genshi seems able to accomplish the message extraction, but later fails on the required runtime translation. This has been discovered first with ScreenshotsPlugin, and the workaround is, what we came up there.

ScreenshotsPlugin does not need the hack. Pass gettext (or _) method with named _ from process_request().

tracscreenshots/core.py

@@ -166 +166 @@
 
         # Return template and its data.
         db.commit()
-        return (template + '.html', {'screenshots' : req.data}, content_type)
+        return (template + '.html', {'screenshots' : req.data, '_': _}, content_type)
 
     # Internal functions.
 

[Steffen Hoffmann]

(In [9435]) AccountManagerPlugin: Improve some i18n related code, closes #8063.

Changes contribute to better code readability and easier understandable msgid's - good for translators, as Jun Omae suggested. Please see #8063 for details. I took the chance to finally remove a leftover from changeset [4638].

[Steffen Hoffmann]

Replying to jun66j5:

Replying to hasienda:

Could you explain ![...]

I think that the calling dgettext in genshi templates is usual. If it's unusual, Chrome.populate_data() should not set dgettext. ![...]

Ok, thanks for the insight given.

This is a hack, since Genshi seems able to accomplish the message extraction, but later fails on the required runtime translation. This has been discovered first with ScreenshotsPlugin, and the workaround is, what we came up there.

ScreenshotsPlugin does not need the hack. Pass ![...]

I'll not forget, but have to look at it later. Thanks for the recommendation. This is an especially clever looking one.

BTW, I've just pushed your Japanese translations out to t-h.o with changeset [9436] and to the back-store of our Transifex translation project at Bitbucket.

Are you sure, the '\n' markers get respected? While you've used them quite a lot, from my own experience with (German) translations I've seen no effect: Line breaks just don't follow these newline positions, neither with English default/fallback nor with my own translations. So I've totally removed them, without noticeable negative effects. Does your experience differ? Is it even depending on some configuration I don't know by now?

[Jun Omae]

Replying to hasienda:

BTW, I've just pushed your Japanese translations out to t-h.o with changeset [9436] and to the back-store of our Transifex translation project at Bitbucket.

Thanks! ;-)

Are you sure, the '\n' markers get respected? While you've used them quite a lot, from my own experience with (German) translations I've seen no effect: Line breaks just don't follow these newline positions, neither with English default/fallback nor with my own translations. So I've totally removed them, without noticeable negative effects. Does your experience differ? Is it even depending on some configuration I don't know by now?

My experience is the same. No such a configration.

When a message is a part of HTML, \n does not effect. Then the removing \n has no problem. When a message is a part of console messages, \n is effective. I translate with care for "Lines shouldn't exceed a length of 79 characters".

[Steffen Hoffmann]

Replying to jun66j5:

Replying to hasienda:

![...] Are you sure, the '\n' markers get respected? ![...]

When a message is a part of HTML, \n does not effect. Then the removing \n has no problem. When a message is a part of console messages, \n is effective. I translate with care for "Lines shouldn't exceed a length of 79 characters".

Don't we have

width = 72

or similar in <pluginroot>/setup.cfg for that purpose? I noticed some of your translations where actually reformatted to have different line break positions when I ran python ./setup.py update_catalog on them, and I do this on a regular base before commits. So your effort may not be effective. Personally I don't care for line breaks in PO files anymore, but write longer lines be intention and let babel tools reformat afterwards.

Thanks for the confirmation in general.

[Ryan J Ollos]

Very minor issue, there is a chunk of whitespace in the textarea. The following is one way to fix it:

acct_mgr/templates/admin_accountsnotification.html

@@ -44 +44 @@
           usernames that get notified of the above actions:
         </p>
         <textarea cols="60" rows="2" id="notify_addresses"
-                  name="notify_addresses">${ ' '.join(notify_addresses)}
+                  name="notify_addresses">
+${' '.join(notify_addresses)}
         </textarea>
       </fieldset>
       <div class="buttons">

[Steffen Hoffmann]

(In [12735]) AccountManagerPlugin: Prevent excessive white space in a textarea, refs #8063.

Thanks to Ryan J Ollos for his hint and proposing a fix.