Modify

Opened 4 years ago

Closed 4 years ago

Last modified 17 months ago

#8063 closed enhancement (fixed)

[Patch] Better i18n codes

Reported by: jun66j5 Owned by: hasienda
Priority: normal Component: AccountManagerPlugin
Severity: normal Keywords: i18n
Cc: Trac Release: 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.
  5. Add %(link)s named-parameter. The separated message makes the translations difficult.

Please apply the patch, if you can.

Attachments (1)

better-i18n.diff (5.7 KB) - added by jun66j5 4 years ago.

Download all attachments as: .zip

Change History (9)

Changed 4 years ago by jun66j5

comment:1 in reply to: ↑ description ; follow-up: Changed 4 years ago by hasienda

  • Status changed from new to assigned

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.

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

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

     
    166166 
    167167        # Return template and its data. 
    168168        db.commit() 
    169         return (template + '.html', {'screenshots' : req.data}, content_type) 
     169        return (template + '.html', {'screenshots' : req.data, '_': _}, content_type) 
    170170 
    171171    # Internal functions. 
    172172 

comment:3 Changed 4 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.
Please see #8063 for details.
I took the chance to finally remove a leftover from changeset [4638].

comment:4 in reply to: ↑ 2 ; follow-up: Changed 4 years ago by hasienda

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?

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

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

comment:6 in reply to: ↑ 5 Changed 4 years ago by hasienda

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.

comment:7 Changed 17 months ago by rjollos

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

     
    4444          usernames that get notified of the above actions: 
    4545        </p> 
    4646        <textarea cols="60" rows="2" id="notify_addresses" 
    47                   name="notify_addresses">${ ' '.join(notify_addresses)} 
     47                  name="notify_addresses"> 
     48${' '.join(notify_addresses)} 
    4849        </textarea> 
    4950      </fieldset> 
    5051      <div class="buttons"> 

comment:8 Changed 17 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.

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from hasienda. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.