Modify

Opened 4 years ago

Closed 7 months ago

#7787 closed enhancement (fixed)

Add i18n support

Reported by: hasienda Owned by: hasienda
Priority: normal Component: TagsPlugin
Severity: major Keywords: i18n
Cc: rjollos, otaku42 Trac Release: 0.12

Description

TagsPlugin should support localized UI for Trac 0.12.

As the change could be done in a backwards-compatible style, we'll retain capability to deploy the resulting code in with Trac 0.11.

Attachments (0)

Change History (12)

comment:1 Changed 4 years ago by hasienda

  • Cc otaku42 added
  • Owner changed from otaku42 to hasienda

As I'm almost finished and agreed with Michael to apply this to trunk on my own, I'll just change responsibility to myself.

comment:2 Changed 4 years ago by hasienda

(In [9316]) TagsPlugin: Add basic i18n setup and message markup, refs #7787.

First extracted messages template and German translations are included
as well.
However, I'd like to make tag realms translatable as well,
before I consider this task as completed.

comment:3 Changed 4 years ago by pacopablo

[9316] causes the same issue as #7850 when installing from source and not using translations. As detailed in #7850, the simple fix is to "force" the egg to include the locale directory.

I think this is fairly big as it effectively breaks most English installs that upgrade.

comment:4 Changed 4 years ago by hasienda

(In [9332]) TagsPlugin: Apply fix for packaging without compiled message catalogs, refs #7787.

This is similar to changesets [9330:9331] for AccountManagerPlugin.

comment:5 Changed 4 years ago by hasienda

(In [9335]) TagsPlugin: Correct i18n replacement modules import, refs #7787.

comment:6 Changed 4 years ago by jun66j5

Hi Steffen,

The msgid is not simple for help of query syntax at tagsplugin/trunk/tractags/templates/tag_view.html@9316#L39.

It would be better to add i18n:msg="" to each node in the help.

  • tractags/templates/tag_view.html

     
    3636        </div> 
    3737        <div> 
    3838          <p><strong>Query syntax:</strong></p> 
    39           <ul i18n:msg=""> 
    40             <li>Use <strong>tag1 tag2</strong> to match <em>all</em> tags.</li> 
    41             <li><strong>tag1 or tag2</strong> will match <em>any</em> tag.</li> 
    42             <li>Negate a tag with <strong>-tag1</strong>.</li> 
    43             <li>Group sub-queries with <strong>(tag1 or tag2)</strong>.</li> 
    44             <li>Quote strings to include special characters.</li> 
    45             <li>Restrict search to a specific realm with <strong>realm:wiki</strong>.</li> 
     39          <ul> 
     40            <li i18n:msg="">Use <strong>tag1 tag2</strong> to match <em>all</em> tags.</li> 
     41            <li i18n:msg=""><strong>tag1 or tag2</strong> will match <em>any</em> tag.</li> 
     42            <li i18n:msg="">Negate a tag with <strong>-tag1</strong>.</li> 
     43            <li i18n:msg="">Group sub-queries with <strong>(tag1 or tag2)</strong>.</li> 
     44            <li i18n:msg="">Quote strings to include special characters.</li> 
     45            <li i18n:msg="">Restrict search to a specific realm with <strong>realm:wiki</strong>.</li> 
    4646          </ul> 
    4747        </div> 
    4848      </form> 

comment:7 Changed 4 years ago by hasienda

I know the deep tag structure in this particular part is not trivial to translate.

OTOH I know this is no problem especially for you. Trac itself has similar msgids, and they explicitly aimed at binding msgid's together in a late phase before release of Trac 0.12 . So what is so particularly wrong about having all this in one chunk. I think translators get a better sense of actual meaning of texts, if it isn't broken up too much.

Actually just removing the markup from <ul> HTML tag could do the job. IIRC I added it by intention to bind previously separated lines together. Of course your patch would still generate the intended msgid per line, no question.

comment:8 follow-up: Changed 4 years ago by jun66j5

I understood your intention for the message. Use your judgment.

Actually, I was confused when I look the msgid. I felt "the msgid contains [1:...], [2:...], ... and [13:...]. it is complicated".

"[1:Use [2:tag1 tag2] to match [3:all] tags.]\n"
"            [4:[5:tag1 or tag2] will match [6:any] tag.]\n"
"            [7:Negate a tag with [8:-tag1].]\n"
"            [9:Group sub-queries with [10:(tag1 or tag2)].]\n"
"            [11:Quote strings to include special characters.]\n"
"            [12:Restrict search to a specific realm with "
"[13:realm:wiki].]"

IMO, It does not need grouped parameters [1:...] ... [13:...] in the translations.

comment:9 in reply to: ↑ 8 Changed 4 years ago by hasienda

Replying to jun66j5:

I understood your intention for the message. Use your judgment.

Sure, I will. But I value your translator and developer feedback too.

![...]
IMO, It does not need grouped parameters [1:...] ... [13:...] in the translations.

Right. This is not absolutely required neither in a technical nor in a logical sense. But I feel the translators get a better sense, if they see closely connected strings as they are. And my feeling was, that putting the whole text block into one msgid improved the understanding for the required translation. The complicated looking markup is required only to fit arbitrary chars back into the HTML tags.

But I'm sure you know especially the last thing for ages. So it boils down to a practical and esthetically issue: Will the average translator succeed in replicating the original structure? Is it nicer to have six consecutive lines (that may be not obviously connected, if I don't add TRANSLATOR: comments in. Or better have the text block with all the ugly markup scattered all over it - as we have it now.

Could we agree, that I'll change from multi to single line, if more people complain? How about a translator vote? I'll open one, if you do not strongly disagree to this kind of invitation to give feedback on this issue.

comment:10 Changed 3 years ago by hasienda

(In [10414]) TagsPlugin: (i18n) Free tag_ from multiple args, closes #8684, refs #7787.

tag_( is meant as a simple replacement for tag(_(, and nothing more.
So splitting the Genshi Element constuction into more stages resolves issues
reported for plugin applications in Trac 0.11, but add

  • better PEP8 conformance (max. 79 chars/line)
  • another TRANSLATOR comment regarding the label text surrounding the link

as well, if changing something here. So import of tag_ is obsolete here.

comment:11 Changed 2 years ago by hasienda

(In [12079]) TagsPlugin: (i18n) Update catalogs, pulling new translations from Transifex too, refs #7787.

We've got translations for

  • Dutch
  • Italian
  • Russian

and even the start for a Telugu translation.

Many thanks to all contributors, and please go on for completing your work.

comment:12 Changed 7 months ago by hasienda

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

In 13815:

TagsPlugin: Completing preparation for v0.7 release.

Availability of that code as stable, tagged release
closes #2429, #3359, #3610, #3624, #3677, #3754, #3864, #3947, #3983, #4078, #4277, #4503, #4799, #5523, #7787, #7857, #8638, #9057, #9058, #9059, #9060, #9061, #9062, #9063, #9149, #9210, #9521, #9630, #9636, #10032, #10416, #10636, #11096, #11147, #11152, #11274, #11302, #11658 and #11659.

Additionally there are some issues and enhancement requests showing progress,
but known to require more work to resolve them satisfactorily, specifically
refs #2804, #4200, #8747 and #9064.

Thanks to all contributors and followers, that enabled and encouraged a good
portion of this development work.

Add Comment

Modify Ticket

Action
as 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.