[EMAIL PROTECTED] writes: > In general my preference is for simplicity -- unfortunately, > simplicity for the user does not necessarily translate into > simplicity for the developer and vice versa.
What I'm more worried about is reliability. Simplicity for the user often means loss of reliability when you try and cut corners. > Of course, it's nicest if you get simplicity in both places! Agreed. The world of I18N e-mail is anything but simple unfortunately. In fact, it's one of the grossest hacks I've ever seen. > What I would be happier w/ is something equivalent to what a user > does when composing an email message -- the user doesn't have to > think about mime-encoding at all assuming the mail client is > well-written. I can investigate this, but I shudder to think about how difficult it might be to write a multilingual capable template editor. Think about Japanese input methods for example (Canna, Wnn, etc.) -- these aren't trivial pieces of code. > In general, I am in favor of being able to specify things explicitly. > In this case, a downside of this is that the user has to learn how to > do it. I honestly don't think that it will be that difficult for the user once I document the process. To be honest, I think there are many other aspects of TMDA configuration that are more difficult. For Japanese, the user will already have to read my HOWTO to realize he needs to use only EUC-JP in his templates, and in the same section it will explain how to modify the header suffix and BodyCharset. And as I mentioned before, if you maintain a site installation, you can change the default templates to EUC-JP encode the body and From/Subject headers, so the user will not have to do this. He will only have to customize the content if he so desires. > I think what you suggest about seeing if there is an actual need > makes a lot of sense. Yup. I think we'll have to do the best we can, and then lay it on the populous for wider feedback. We can always make adjustments based on this. > [1] As a side note, I suppose since Singapore has 3 languages in > more-or-less widespread use and IIUC people who grow up there are > required to choose 2, there'd be cases where English might be > neither of these. But then, perhaps it's more likely that > messages would have 3 languages (including English) Right now, I'm only planning on supporting one charset for the body of the message (again assuming most will write in English + native language, or just their native language). Often, this will suffice for multiple languages if the charset encompasses all. For example, ISO-8859-1 covers French as well as Swedish. ISO-8859-2 covers both German and Polish. And of course both of these cover English. However, if someone wants to use multiple languages, and those languages use conflicting charsets, they have a problem. For example, you can't mix KOI8-R (Russian) and ISO-2022-JP in the same body without including them as separate MIME bodyparts. This again falls into the category of "lets cross that bridge when we come to it". My focus with this first round was to cover most user's multilingual needs without changing the existing template system much. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
