Edgewall Software

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#10749 closed defect (fixed)

`babel.Translations.load({...}).install()` from a plugin breaks the loaded translations catalog — at Version 11

Reported by: Jun Omae Owned by: Jun Omae
Priority: normal Milestone: 1.0
Component: i18n Version: 0.12
Severity: normal Keywords:
Cc: ryano@… Branch:
Release Notes:

Correctly handle multiple i18n domains in JavaScript translations.

API Changes:
Internal Changes:

Description (last modified by Jun Omae)

generate_messages_js command of setuptools works for Trac and Trac plugins. The command generates "messages file for javascript" as the following; 

// Generated messages javascript file from compiled MO file
babel.Translations.load({"domain":"{plugin-name}-js",...}).install();

The babel.Translations.install() installs _, genetext and ngettext functions binded the loaded translations instance to window instance.

When a plugin loads the messages catalog for javascript, Therefore, it overwrites the last installed functions (maybe from trac/htdocs/messages/*.js) and messages for Trac will not be translated.

Related branches

Change History (12)

comment:1 by Jun Omae, 12 years ago

Description: modified (diff)

comment:2 by Christian Boos, 12 years ago

Looks sound. Unfortunately, I don't have a quick way to try this by myself, so feel free to apply.

in reply to:  2 comment:3 by Jun Omae, 12 years ago

Resolution: → fixed
Status: new → closed

Replying to cboos:

Looks sound. Unfortunately, I don't have a quick way to try this by myself, so feel free to apply.

Applied in [11101]. Thanks.

comment:4 by Jun Omae, 12 years ago

Owner: set to Jun Omae

by Ryan J Ollos <ryano@…>, 12 years ago

Attachment: Comment1.png​ added

comment:5 by Ryan J Ollos <ryano@…>, 12 years ago

Strange that the heading for comment:1 is shown even though Comments only is selected. Even more strange is that I can't reproduce this behavior in a dev instance of r11100, or on the demo site, which is at r11050.

comment:6 by Peter Suter, 12 years ago

I think comment:1 contains a newline, so it isn't considered empty. (Reproduce it on the ​demo-0.13 site by pressing the Enter key in the comment field before submitting.)

comment:7 by Remy Blank, 12 years ago

We could strip the comment when checking if it's empty.

in reply to:  7 ; comment:8 by Ryan J Ollos <ryano@…>, 12 years ago

Replying to rblank:

We could strip the comment when checking if it's empty.

The behavior seems closely related to the patch in #10748, so I'll add to my todo list to handle this case as part of that patch as well.

Last edited 12 years ago by Christian Boos (previous) (diff)

comment:9 by Ryan J Ollos <ryano@…>, 12 years ago

Cc: ryano@… added

in reply to:  8 comment:10 by Ryan J Ollos <ryano@…>, 12 years ago

Replying to Ryan J Ollos <ryano@…>:

The behavior seems closely related to the patch in #10748, so I'll add to my todo list to handle this case as part of that patch as well.

Issue has been addressed in the following patch ticket:10748:t10748-r11103-1.patch​

Last edited 12 years ago by Christian Boos (previous) (diff)

comment:11 by Christian Boos, 12 years ago

Release Notes: modified (diff)
Note: See TracTickets for help on using tickets.