Untranslated buttons in spam filter admin panel

[Jun Omae]

After [14814,14815], labels in the buttons of spam filter admin are untranslated.

The gettext in tracspamfilter.api is not the same as gettext in trac.util.translation. Instead, we should use dgettext and dngettext with tracspamfilter catalog like this:

-        <input type="submit" name="cleantemp" value="${ngettext('Remove %(num)s temporary session',
+        <input type="submit" name="cleantemp" value="${dngettext('tracspamfilter', 'Remove %(num)s temporary session',

Those translation methods can easily be replaced by sed.

for i in tracspamfilter/templates/*.html; do
  sed -i \
    -e "s/\<_(/dgettext('tracspamfilter', /g" \
    -e "s/\<gettext(/dgettext('tracspamfilter', /g" \
    -e "s/\<ngettext(/dngettext('tracspamfilter', /g" \
    $i
done

[Ryan J Ollos]

Thanks for spotting. I'll apply your fix today.

[Ryan J Ollos]

Fixed in [14842].

[Christian Boos]

Ok, so this fixes a regression in r14814, but wasn't that change a mistake in the first place?

With r11363 + r11377, you can see that the intent of replacing the _ function used in templates with the tracspamfilter.api._ one (which wraps the 'tracspamfilter' domain gettext function), was to keep the simplicity of _("...") instead of having to write the lengthier dgettext('tracspamfilter', "...") as you did in r14842.

See CookBook/PluginL10N#MakethePythoncodetranslation-aware for details on domain_functions. I should probably also document the data['_'] = _ trick in the next section, CookBook/PluginL10N#MaketheGenshitemplatestranslation-aware (unless, of course, you see a reason to not do things this way).

[Ryan J Ollos]

Yes, it was a mistake. However, I'm not sure it's worth changing until porting the templates to Jinja2.

[Jun Omae]

Replying to Christian Boos:

See CookBook/PluginL10N#MakethePythoncodetranslation-aware for details on domain_functions. I should probably also document the data['_'] = _ trick in the next section, CookBook/PluginL10N#MaketheGenshitemplatestranslation-aware (unless, of course, you see a reason to not do things this way).

I don't think we should use data['_'] = ... trick in Genshi template. The _ variable is used in layout.html and theme.html, … in Trac core and expects messages domain. For example, Search msgid exists in another text domain (which is provided from a plugin), it can be translated to unexpected text.

[Christian Boos]

Replying to Jun Omae:

I don't think we should use data['_'] = ... trick in Genshi template. The _ variable is used in layout.html and theme.html, … in Trac core and expects messages domain. For example, Search msgid exists in another text domain (which is provided from a plugin), it can be translated to unexpected text.

Ok, I don't think this is very likely, but point taken. Well, we could pick another shorthand then (e.g. __, also adding it as a keyword in the appropriate setup.cfg section). I think that dgettext('<domain>', "...") should really be reserved for the rare case in which <domain> is not the expected domain, as repeating 'tracspamfilter' everywhere as we do in r14842 seems heavy handed.

[Christian Boos]

sReplying to Ryan J Ollos:

Yes, it was a mistake. However, I'm not sure it's worth changing until porting the templates to Jinja2.

By the way, I have yet to find a way to support translation domains in Jinja2 trans directives…