Add i18n support

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

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

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

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

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

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

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.

Index: tractags/templates/tag_view.html
===================================================================
--- tractags/templates/tag_view.html    (revision 9409)
+++ tractags/templates/tag_view.html    (working copy)
@@ -36,13 +36,13 @@
         </div>
         <div>
           <p><strong>Query syntax:</strong></p>
-          <ul i18n:msg="">
-            <li>Use <strong>tag1 tag2</strong> to match <em>all</em> tags.</li>
-            <li><strong>tag1 or tag2</strong> will match <em>any</em> tag.</li>
-            <li>Negate a tag with <strong>-tag1</strong>.</li>
-            <li>Group sub-queries with <strong>(tag1 or tag2)</strong>.</li>
-            <li>Quote strings to include special characters.</li>
-            <li>Restrict search to a specific realm with <strong>realm:wiki</strong>.</li>
+          <ul>
+            <li i18n:msg="">Use <strong>tag1 tag2</strong> to match <em>all</em> tags.</li>
+            <li i18n:msg=""><strong>tag1 or tag2</strong> will match <em>any</em> tag.</li>
+            <li i18n:msg="">Negate a tag with <strong>-tag1</strong>.</li>
+            <li i18n:msg="">Group sub-queries with <strong>(tag1 or tag2)</strong>.</li>
+            <li i18n:msg="">Quote strings to include special characters.</li>
+            <li i18n:msg="">Restrict search to a specific realm with <strong>realm:wiki</strong>.</li>
           </ul>
         </div>
       </form>

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.

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.

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.

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

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