Opened 3 years ago

Closed 3 years ago

# [Patch] Better i18n codes

Reported by: Owned by: jun66j5 hasienda normal AccountManagerPlugin normal i18n 0.12

### Description

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.

Please apply the patch, if you can.

### comment:1 in reply to: ↑ description ; follow-up: ↓ 2 Changed 3 years ago by hasienda

• Status changed from new to assigned

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.

### comment:2 in reply to: ↑ 1 ; follow-up: ↓ 4 Changed 3 years ago by jun66j5

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

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

### comment:3 Changed 3 years ago by hasienda

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

(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.
I took the chance to finally remove a leftover from changeset [4638].

### comment:4 in reply to: ↑ 2 ; follow-up: ↓ 5 Changed 3 years ago by 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?

### comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 3 years ago by jun66j5

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

### comment:6 in reply to: ↑ 5 Changed 3 years ago by 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.

### comment:7 Changed 9 months ago by rjollos

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

 usernames that get notified of the above actions:

### comment:8 Changed 9 months ago by hasienda

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

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

### Modify Ticket

Change Properties