i18n for the "reasons" for rejecting spam

[Christian Boos]

One last i18n update for today, on the SpamFilter.

But as it's non-trivial, I'd like to get some review on it before committing. Maybe I overlooked something…

The idea is to keep the model as is, and continue storing the reasons for changes like usual ("<filter-name> (score): reason for rejection (optional detail)"). The trick is to "parse" it back, in its four constituents.

Then I first tried to render it back in the template, but that was too much logic for too few markup, the code had to be duplicated in admin_spammonitor.html and admin_spamentry.html or a py:def macro should have been used, but an included template containing just that function would have been overkill as well.

So I think having a _render_reasons function in the code is not too bad. Next, I'll probably try to see how moving that to Javascript would look like (in the spirit of doing less server side and more client side).

[Christian Boos]

the reasons retrieved from the log entries are now translated

[Peter Suter]

Don't you also need _encode_reasons()? (From a list of tuples back to a list of strings so '\n'.join(reasons) in LogEntry.update() and LogEntry.insert() works again.)

[Christian Boos]

Yes, good suggestion. Moreover, by looking closer at this side of the code (how reasons are retrieved from each filter strategy and passed to LogEntry), I see that the "detail" part might be a tuple…

#: tracspamfilter/filters/defensio.py:90
msgid "Defensio says content is not allowed (%s, %s, %s)"

#: tracspamfilter/filters/trapfield.py:58
msgid "Both trap fields says this is spam (%s, %s)"

… which complicates a bit the problem (I knew I overlooked something ;-) ).

[Christian Boos]

encode/decode reasons in LogEntry; the rest of the code should manipulate reasons as structured objects, not as text

[Dirk Stöcker]

Do I understand you right, that you want to store the text form and convert it back into structure? That wont work for a lot of languages.

The correct way is to store the individual entries in the LogEntry. I thought about using \x01 and \x02 as field separator and simply join them. Then they can easily be split again and there is no need to change the database structure.

[Christian Boos]

Well, we only ever store the original (i.e. english) messages, don't we?

In the patch there's no change in what is currently stored; the only change is to parse it back in such a way that it can be translated again.

And if we do want to change the way the reasons are stored, then better use some neutral text representation (XML or JSON), rather than binary separator, as that would require at least in addition a base64 encoding (the way we do it for content).

[Dirk Stöcker]

XML sounds good to me. Is also easy detectable to handle old entries.

[Dirk Stöcker]

In r11750.

I don't know any remaining part which is not i18n clean. Only french translation needs updating a lot :-) German is complete…