Re: Spamfilter-plugin

[Christian Boos]

Hello Dirk,

First, let me CC: trac-dev, as the main issues are not with you misusing
the i18n, but rather about a few new undocumented features of 1.0.

On 9/25/2012 10:39 AM, Dirk St�cker wrote:
> Hello,
>
> I have another thing one of you can help me. I started I18N of
> spam-filter-plugin, but I can't find a proper place for the add_domain
> call. At least everything I tried failed till now.
>
> The SVN-code does not contain add_domain calls now. I tried in
> filtersystem.py and in admin.py, both failed.

Ok, add_domain is really needed, without it the messages will only be
fetched from the Trac catalog "messages.po" which contains none but a
few of the required translations (you may get by luck some of them, like
the one for "Author").

But as you found out, even when adding a proper call to add_domain, the
translations still won't show up...

>
> Can anyone of you two have a look and tell me whats wrong? I already did
> partial "de" translation, but can't get it working.
>

First problem: you try to translate the TracIni documentation.
Using _() for that is not OK, as this will try to get a translation at
module loading time, where no locale is yet set up. The strings should
be only marked for translations, using N_ (or better, cleandoc_, if you
add it to your setup.cfg as an extractor tag *and* you make sure that
the special trac.dist.extract_python extractor is used!). And finally,
the domain has to be specified for each option instance, using
doc_domain='tracspamfilter'.

Well, I realize the documentation for these new 1.0 features (#9666,
#10038) there should probably be a note in the L10N pages, like an
expanded version of the above together with an example in the
CookBook/PluginL10N.

Second problem: the Genshi templates. You were missing the
xmlns:i18n="http://genshi.edgewall.org/i18n" namespace declaration,
but also the i18n-domain directive.

Again, something which could be more clearly documented.

> Are there any possibilities to debug where the error lies?

Well, short of adding a few debug statements, I don't think so.

So, for the way forward, I'll try to find some time this evening to fix
the docs and I could also commit the changes I've done on the
plugins/1.0/spam-filter if you're OK with that.

-- Christian

[Dirk Stöcker]

On Tue, 25 Sep 2012, Christian Boos wrote:

> So, for the way forward, I'll try to find some time this evening to fix
> the docs and I could also commit the changes I've done on the
> plugins/1.0/spam-filter if you're OK with that.

Go on. This is the reason why it is SVN :-)

Still I do understand only half of what you said and this with nearly 20
years of experience in translating software and making software ready for
translation. So I expect others to have much more problems.

Beside the fixes/updates in documentation, links to working plugin example
codes would be a good idea. Usually working code is much better to
document stuff than the best web page.

One note: It seems
<p i18n:msg="x,y">
<py:if...>${x}</py:if>
<py:if...>${y}</py:if>
</p>

does not work, I have to use
<p i18n:msg="x,y">
<span py:if...>${x}</span>
<span py:if...>${y}</span>
</p>

which is nearly, but not exactly the same. I think this should be fixed
(in Genshi?).

Ciao
--
http://www.dstoecker.eu/ (PGP key available)

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 25.09.2012 20:32, Dirk St�cker wrote:
> Still I do understand only half of what you said and this with nearly 20
> years of experience in translating software and making software ready
> for translation. So I expect others to have much more problems.

Sure. I'm doing this i18n work for about 3 years now. And until now
every plugin had another challenge.

> Beside the fixes/updates in documentation, links to working plugin
> example codes would be a good idea. Usually working code is much better
> to document stuff than the best web page.

I think, that the cookbook page [1] has some good pointers. But you can
always make it better, sure.

Existing code is a great resource, yes, and there are commits/series of
commits, that show general patters for making a Trac plugin i18n-ready.
I.e. Simon recently did it for CustomFieldAdminPlugin [2].

For some corner-cases you may still want to call for help. I think, that
Jun Omae is on of the i18n gurus here. He contributed a lot of the
i18n-related code and plugins he maintains were among the first with
i18n-support. Christian, as I already know, is another good partner for
this kind of work.

Being not among the core developers I'm still trying to support
i18n-related work too as much as I can. I made the proposal to join Trac
plugin translation work [3]. The idea is to allow for standardized
translations with unified terms, and don't require translators to dig
through repositories to find existing catalogs.

Transifex software upgrades made me stumble for some months, but I'm
catching up now. And I'll include much more plugins, that got i18n-ready
lately.

Steffen Hoffmann


[1] http://trac.edgewall.org/wiki/CookBook/PluginL10N
[2] http://trac-hacks.org/changeset/11168
[3] http://trac-hacks.org/wiki/TracPluginTranslation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlBiDm0ACgkQ31DJeiZFuHfv3gCeJh1HyVRqmKcr4ObPokrFTOX8
/asAoLWTcCniaNtczx5lJxiWwopfjX5M
=hm7M
-----END PGP SIGNATURE-----

[Dirk Stöcker]

On Tue, 25 Sep 2012, Christian Boos wrote:

> So, for the way forward, I'll try to find some time this evening to fix
> the docs and I could also commit the changes I've done on the
> plugins/1.0/spam-filter if you're OK with that.

For the _() inside python code in the html templates (e.g. spamentry) the
translation does not work. For SpamEntry "yes" and "no" are translated,
but not the rest, so I asume the domain setting is still wrong for this
part of code.

Biggest problem are the spam results. Instead of compiled texts I need to
keep text and values separate and only translate when finally displayed.
Needs some rework in code structure :-)

[Christian Boos]

On 9/26/2012 9:32 PM, Dirk St�cker wrote:
> On Tue, 25 Sep 2012, Christian Boos wrote:
>
>> So, for the way forward, I'll try to find some time this evening to fix
>> the docs and I could also commit the changes I've done on the
>> plugins/1.0/spam-filter if you're OK with that.
>
> For the _() inside python code in the html templates (e.g. spamentry)
> the translation does not work. For SpamEntry "yes" and "no" are
> translated, but not the rest, so I asume the domain setting is still
> wrong for this part of code.

Well spotted! Yes, the "_" present in the templates refers to the
standard "_", not the domain-equipped one from the plugin. One need to
override it in the plugin's render_admin_panel() methods (`data['_'] = _`).

See http://trac.edgewall.org/changeset/11377 for that and some more...

>
> Biggest problem are the spam results. Instead of compiled texts I need
> to keep text and values separate and only translate when finally
> displayed. Needs some rework in code structure :-)

I'll happily let you do that ;-)

-- Christian