Tim Legant <[EMAIL PROTECTED]> writes: > Playing at psychologist for a moment, I would suspect that if > someone is going to the trouble of providing a native language > translation, say, for incoming mail from .de domains, they would > want that first, then the English.
Yup, it's hard to say. I'd like to hear from some TMDA users who do use multilingual templates. I'll probably ask on -users if noone else responds here. > On the other hand, if we can support letting them configure it, I'm > all for that. Then we don't have to guess. The reason I asked is because I'm trying to decide how literally to follow RFC 1892, which is what I'm considering using for the new MIME-based auto-replies. The RFC recommends use of a multipart/alternative construct to hold alternative versions of the same information. In our case, the report would be say a confirmation request containing 1 to N translations of the instructions. multipart/alternative is perfectly suited for this because it would allow the user to select the language he wants to read instead of having all the translations listed sequentially. The problem with multipart/alternative though for translated texts is that the sender can't control which version the recipient will see by default. That's controlled by the recipient's MUA. The rule (rfc 2046, section 5.1.4) says user-agents should choose the LAST part of a type supported by the local environment. Well, my environment (a MULE-ized XEmacs) supports practically every charset out there, but that doesn't mean I can read most of those languages. This means if a TMDA user wants to include both German and English templates, and show German by default, it will have to be inserted in reverse order: English, then German. However, this means non-MIME mail readers will not see German first because the English is there first. So, there seems no way to control this using multipart/alternative. What I thought of doing instead is use a multipart/mixed MIME part. This way the recipient will see the templates in the order the sender intended. The downside being that every recipient will have to look at every language included. Thoughts? _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
