[Mailman-Developers] prevent qp as qp routine broken

[Michael Heydekamp]

Hi Simone,

Simone Piunno <pioppo at ferrara.linux.it> to Michael Heydekamp on
25.01.04:

> On Sunday 25 January 2004 15:45, Michael Heydekamp wrote:

>>> There's no such text in the german translation for 2.1...
>>> neither in subscribeack.txt, nor anywhere else.

>> Of course not, this is a list specific subscribeack.txt that I
>> created for each of our lists.

> Ah ok, maybe we're getting closer to the solution...

Let's see...

>> But what the heck :) has the (arbitrary) text itself to do with the
>> fact that Mailman creates a technically wrong and therefore ugly
>> qp'd output upon sending such texts?  It would do so with the
>> original subscribeack.txt in exactly the same manner.

> That text is not completely arbitrary: there's a little structure in
> those apparently flat files!
> The rationale is that, after variable interpolation, the text could
> become more ugly than you reported, because we don't know in advance
> how many chars will be used for each interpolation placeholder.

The text that I quoted did not contain any variables, Simone.

> For this reason, after interpolation in Utils.maketext() the
> resulting string is filtered by Utils.wrap(), which basically reflows
> all not-indented paragraphs.

This *is* an indented paragraph (with a negative indention in the first
line).  Quite common thing...

And the wrapping is done at a fixed position of ...?

I also had cases where an empty line was inserted in the middle of a
paragraph for no reason (for instance in the result of a 'help'
request).

> Probably you wrote your templates without taking care of these rules,
> and get ugly results.

Are these rules documented somewhere?

Anyway, when writing these texts, I was of course bearing in mind
possible variable interpolation and made sure that lines with variables
cannot exceed a reasonable line length.

> If you want to completely disable the re-flowing logic, you should
> add a "raw=True" parameter to Utils.maketext() calls (e.g. at line 58
> of Deliverer.py), or just change the defaults (at line 384 for
> Utils.py),

Ah, I'll try that.  Thanks!

> by I bet after some experimentation you'll prefer to rollback ;)

Never ever. :)  I hate when software is messing up my carefully prepared
text files without asking me.

>> Simone, there is BTW still another open question in
>> <91HicwPppwB at my.freexp.de> (how to make fuzzy translations
>> non-fuzzy).

> You simply fix that translation string (if needed) and remove the
> fuzzy line.

But as I told you already in the message above:

----------8<----------
> But as I said: Even if I remove the tag and recompile the file, the
> translation is still not used.  What's wrong?
----------8<----------

I thought it might have to do with the fact that the English text
additionally appears in line 17 of cmd_confirm.py, but I'm not sure
what's this for?

I also don't know if the line numbers in the language file do have any
effect (apart from being informational), but we can discuss this in the
appropriate mailing list as soon as I have accomplished some Exim stuff
here...


        Michael