update the 0.12 branch to bring in i18n

[Steffen Hoffmann]

You've already created a i18n branch and kindly granted SVN commit for contributions.

Since I've put out a preliminary version for testing now, let's track all issues with this WiP here.

[Martin Scharrer]

Thanks for the i18n support. I will update the 0.12 branch as soon my busy schedule permits it.

[Martin Scharrer]

I checked the German translation and found some strings which could be improved. Sometimes the exact context was not taken into account or matching strings (e.g. "do/do not" strings) where translated in a different style.

Sometimes the words "Wikis" and "Tickets" are missing, e.g. in "Watched Wikis". The locate files only hold "Watched ", while here the whole string should be translated to also allow for different grammar etc.

I also start to think that several messages should be reformatted in the python code to allow for better translations. What do you think?

[Martin Scharrer]

Some suggestions for the German language locales.

[Steffen Hoffmann]

Replying to martin_s:

I checked the German translation and found some strings which could be improved.

Sure, that's what I expected and talked about in direct mail to you. I've done some improvements now, will attach here for discussion, but personally I'd hesitate to merge back (to dev) before this has settled quite a bit. Such changes is exactly what this branch is for, right? Too much changes in more official branches would give early translators much frustration, so should be generally avoided. The first steps were just pushed to show general direction of i18n work.

Sometimes the exact context was not taken into account or matching strings (e.g. "do/do not" strings) where translated in a different style.

Watch out for replacement markers like %(realm)s, that get substituted on-the-fly by i.e. wiki or ticket. Other than that there are possibly some mistakes in early stage, will try to fix them in currently prepared changeset.

Sometimes the words "Wikis" and "Tickets" are missing, e.g. in "Watched Wikis". The locate files only hold "Watched ", while here the whole string should be translated to also allow for different grammar etc.

Sure this is exactly the work to be done now. I'll fix this.

I also start to think that several messages should be reformatted in the python code to allow for better translations. What do you think?

Well, the next revision will look much better to you, however I'm struggling with a nasty 'IndexError: list index out of range' when including variable content like 'new_res[0]' into a msgid. I need to investigate further, but maybe there is currently no better solution than to got with the sentences broken into short msgid's where ever such a variable is encountered, or to work around that somehow.

[Steffen Hoffmann]

Replying to martin_s:

I checked the German translation and found some strings which could be improved. .. What do you think?

Thanks for your suggestions. Just some quick notes regarding msgid

"Watchlist"

de:Lesezeichen was just my take on the subject, but we'll certainly try to be consistent, so de:Beobachtungsliste or similar is the way to go

"You are now watching this resource."

resource <> de:Seite, since resource = [page, ticket] There is even another, similar msgid announcing stopped watching.

"Do not Notify me"/"Notify me"

There was shortness vs. textual similarity, but if you really prefer the latter, ok.

I'm just fine with the others, will merge now and upload another one here for further discussion.

[Steffen Hoffmann]

development version of locale/de/LC_MESSAGES/watchlist.po for discussion

[Steffen Hoffmann]

How do you think about a resource name wrapper. The current 'name.capitalize()' shorthand produces fixed names 'Tickets' and 'Wikis'. This is ok for English, at least acceptable in German (while de:Wikiseiten would still be preferable), but totally unacceptable in other languages, right?

[Martin Scharrer]

Replying to hasienda:

How do you think about a resource name wrapper. The current 'name.capitalize()' shorthand produces fixed names 'Tickets' and 'Wikis'. This is ok for English, at least acceptable in German (while de:Wikiseiten would still be preferable), but totally unacceptable in other languages, right?

Yes, I was thinking about that, too. We would need one for plural and one for singular. Any idea how to implement this consistently? In principle more watchable categories can be added using the coming-up interface, which might be tricky to handle.

[Martin Scharrer]

Another thought:

Should we translate the date/time format in the "last changed at" columns? I already made related changes in the dev branch: See here​

For English I use the format "%F %T %Z", which could be translated like any other string. See ​http://php.net/manual/en/function.strftime.php for the list of valid format parameters.

On second thought: there might also be a standard translation for this, which we should use.

[Steffen Hoffmann]

Good point, best to read and use time format settings from currently selected locale. I've encountered this before, will take a look and just do it.

Would you really bother writing singular:Wiki|plural:Wikis to the header? I guess there is limited use for such a refinement in some action/confirmation message texts, however looks not too important to me.

The current messages are reasonably generic to apply for both just one as well multiple item. Better have translated field names in first. Still I'll keep an eye on this, maybe I'm wrong in some cases.

[Steffen Hoffmann]

Replying to martin_s:

Replying to hasienda:

How do you think about a resource name wrapper. The current 'name.capitalize()' shorthand produces fixed names 'Tickets' and 'Wikis'. This is ok for English, at least acceptable in German (while de:Wikiseiten would still be preferable), but totally unacceptable in other languages, right?

Yes, I was thinking about that, too. We would need one for plural and one for singular. Any idea how to implement this consistently?

I'll push my suggestion to i18n branch.

In principle more watchable categories can be added using the coming-up interface, which might be tricky to handle.

Well, you did prepare quite nicely in advance AFAIKS: get_realm_label is already there, and I just need to change it to (optionally?) return localized names. If all categories where added under your control, this would just require a catalog update, like any other message change in plugin's code. But if you still think additions could be done as a separate plugin, this would require the autor to do the i18n stuff on it's own. Anyway, I can't see a big problem either way.

[Martin Scharrer]

get_realm_label could return plural and singular version of the realm label.

[Martin Scharrer]

I'm just wondering (because of #7660): Is the current code in the i18n or dev branch also compatible with Trac 0.11? The other 0.12 related changes are only for the time stamp which could be implemented with 0.11 fallbacks.

I would like to be able to easily release 0.11 versions from the newer code as well.

[Martin Scharrer]

I was going ahead and made the dev branch again compatible with Trac 0.11 by providing fall-back functions for the i18n/l10n and micro second functions: [8724]

I tested this successful with Trac 0.11, 0.11.7 and 0.12 .

[Steffen Hoffmann]

Only had time to look into this right now. What I've seen so far is correct. Didn't know about existence of trac.util.translation in Trac 0.11 before. I would have made a simple "pass-through" translation dummy function instead like

    def _(str):
        return str

But your solution certainly superior, since it's not home-brew and tested. Very well.

[Martin Scharrer]

Replying to hasienda:

I would have made a simple "pass-through" translation dummy function instead like

    def _(str):
        return str

:-D That was also my first idea! Ok, I had def _str(text): return text, but then remembered from the info I got from your ​babel ticket #238 that '_' also can also take **args, and remembered about seeing the 0.11 no-op function.

[Steffen Hoffmann]

I've taken a second look at changeset [8724] and I don't think, that you should have a pass-through replacement for from_utimestamp. In fact, if the import fails, it's safe to assume that timestamp storage is former POSIX seconds format (any Trac before 0.12dev-​r9210), so plugin should work with to_timestamp instead to get objects of type datetime.datetime from ticket db table timestamps, right?

[Martin Scharrer]

The fall-back for from_utimestamp (pass through) is functional identical to the current 0.11 branch implementation, which works.

I had a look on the code for Trac (trac.util) and the WatchlistPlugin in both 0.11 and 0.12 version. As far I understand it, it is as follows: (I was quite confused about what is now a timestamps so I write down my findings here, just in case I need to look it up again)

• The DB holds integers (seconds since epoch for 0.11, micro-seconds for 0.12)
• These integers are called timestamps (so to_timestamp isn't needed)
• They can be converted to datetime objects with to_datetime, which is also called by all relevant functions (format_datetime and pretty_timedelta) used by the plug-in.
• The 0.12 function from_utimestamp returns a datetime object for the micro-second integer timestamp.

Because to_datetime seems to accept a ms timestamp and is used by all time related functions I'm even sure anymore that from_utimestamp is really needed for the 0.12 branch! I got the code from #6922. You commented there and said it is required. Please enlighten me.

Anyway, it might be good idea to let from_utimestamp fall back to to_datetime due to the following reasons:

• Both return a datetime object -> Consistent result.
• The DB integer is anyway converted to datetime later, but multiple times! Would be more more efficient to convert it once.

[Martin Scharrer]

(In [8731]) plugin.py:: Made from_utimestamp fall back to to_datetime in Trac 0.11. See #7579 comment:16.

[Martin Scharrer]

Say, it is possible to make i18n/l10n fall back to the normal Trac messages when there is no message defined for the WatchlistPlugin? Some of the wiki and ticket columns are already translated by Trac.

Also I get a funny behaviour after I update the messages: Sometimes the new owns are not used even when I run first python ./setup.py extract_messages and then python ./setup.py update_catalog. I'm using egglinks (created with spython setup.py develop --exclude-scripts) to avoid reinstalling the package after each change (which I did until recently), which might the problem. If I install the package (using easy_install .) the new messages appear.

The really funny thing is that before that it really fell back to Trac messages but not after the reinstall.

[anonymous]

Replying to martin_s:

Say, it is possible to make i18n/l10n fall back to the normal Trac messages when there is no message defined for the WatchlistPlugin? Some of the wiki and ticket columns are already translated by Trac.

Implemented this a while ago by importing the _ method of trac as t_.

Also I get a funny behaviour after I update the messages: Sometimes the new owns are not used even when I run first python ./setup.py extract_messages and then python ./setup.py update_catalog. I'm using egglinks (created with spython setup.py develop --exclude-scripts) to avoid reinstalling the package after each change (which I did until recently), which might the problem. If I install the package (using easy_install .) the new messages appear.

The really funny thing is that before that it really fell back to Trac messages but not after the reinstall.

If figured it out: I didn't know that I had to run python ./setup.py compile_catalog.

[Martin Scharrer]

Replying to anonymous: That was me, just forgot to login.

hasienda, I added WatchlistManual wiki pages for English and German (both quite empty) to the repository. There is now a Help link in the context menu of the watchlist which brings the user to the manual in his language. What do you think about this idea?

[Steffen Hoffmann]

As I already pointed out by email, adding tool-tip pop-ups to input fields could improve usability as well, but this might even be complementary to the wiki page approach. Only I guess, contribution of translations might be not as straight-forward as with the rest of plugin messages, but certainly I have to look at current code more closely, before I know about this for sure.

[Ryan J Ollos]

In 15707:

2.0.0dev: Require Trac >= 0.12

Refs #7579.

[Ryan J Ollos]

The last change on the i18n branch was in r8599. The i18n branch was merged into dev in r8604, and dev became the 0.12 branch in r11371.

[Ryan J Ollos]

In 15708:

Remove obsolete branch

Refs #7579.