translation of mail templates
Hi I started to translate the templates into german, resulting in some nasty unicode errors. Is there a howto on how the translation for other languages has to be done? Peter
Peter,
there should be German translations that come with Mailman 2. Which ones are you trying to translate?
p@rick
Am 20.08.2012 09:18, schrieb Peter Holzer:
Hi I started to translate the templates into german, resulting in some nasty unicode errors. Is there a howto on how the translation for other languages has to be done? Peter
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind....
Security Policy: http://wiki.list.org/x/QIA9
-- state of mind () Digitale Kommunikation www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563
I just took the english templates from MM3 and started to change them. Are the templates the same as in MM2? Anyhow do i have to configure something in MM3 to make these templates work? Peter
agitator - weblösungen Peter Holzer Sumatrastrasse 25 CH-8006 Zürich Tel. +41 43 544 08 85 http://www.agitator.com
On 20.08.2012, at 17:29, Patrick Ben Koetter <p@state-of-mind.de> wrote:
Peter,
there should be German translations that come with Mailman 2. Which ones are you trying to translate?
p@rick
Am 20.08.2012 09:18, schrieb Peter Holzer:
Hi I started to translate the templates into german, resulting in some nasty unicode errors. Is there a howto on how the translation for other languages has to be done? Peter
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/p%40state-of-mind....
Security Policy: http://wiki.list.org/x/QIA9
-- state of mind () Digitale Kommunikation www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht München Partnerschaftsregister PR 563
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/devlists%40irrtum....
Security Policy: http://wiki.list.org/x/QIA9
On Aug 20, 2012, at 06:22 PM, Peter Holzer wrote:
I just took the english templates from MM3 and started to change them. Are the templates the same as in MM2? Anyhow do i have to configure something in MM3 to make these templates work?
The i18n infrastructure is probably not complete in mm3, although the basic should work. We don't really have good extraction of the messages, and we're still undecided on what service, or how, to manage translations. There are lots of options, but what I think really needs to happen is for someone to really take ownership of i18n for mm3. I'm happy to help with the technical side of the core, and the Postorius folks will help with the Django side, but I think we need someone who is really involved in translations to evaluate our options and drive the technical discussion forward.
Cheers, -Barry
- Barry Warsaw <barry@list.org>:
On Aug 20, 2012, at 06:22 PM, Peter Holzer wrote:
I just took the english templates from MM3 and started to change them. Are the templates the same as in MM2? Anyhow do i have to configure something in MM3 to make these templates work?
The i18n infrastructure is probably not complete in mm3, although the basic should work. We don't really have good extraction of the messages, and we're still undecided on what service, or how, to manage translations. There are lots of options, but what I think really needs to happen is for someone to really take ownership of i18n for mm3. I'm happy to help with the technical side of the core, and the Postorius folks will help with the Django side, but I think we need someone who is really involved in translations to evaluate our options and drive the technical discussion forward.
I am not the one to tell about the technical issues, but I can tell <https://www.transifex.com> works well for Modoboa <http://modoboa.org/en/>. They have free accounts for open source projects. It might be a nice way to organize a translation community.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
On Aug 21, 2012, at 02:08 AM, Patrick Ben Koetter wrote:
I am not the one to tell about the technical issues, but I can tell <https://www.transifex.com> works well for Modoboa <http://modoboa.org/en/>. They have free accounts for open source projects. It might be a nice way to organize a translation community.
I saw a demo of them at Pycon. It looked pretty cool.
-Barry
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she thinks?
There are also active translation communities at Debian and Launchpad, and I would assume at Red Hat/Fedora. Both Deb and Ubuntu are happy Mailman users, and I would guess Red Hat/Fedora, too. All probably would find some of the MM3 features very attractive for their own use.
Steve
On Aug 21, 2012, at 01:04 PM, Stephen J. Turnbull wrote:
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she thinks?
Right, that would be Clytie, CC'd here. However, it's been a while since we've heard from her.
There are also active translation communities at Debian and Launchpad, and I would assume at Red Hat/Fedora. Both Deb and Ubuntu are happy Mailman users, and I would guess Red Hat/Fedora, too. All probably would find some of the MM3 features very attractive for their own use.
Definitely, and I've looked at all of the various translation services, mostly from the point of view of a project manager non-translator. E.g. how would I push updates into the service, how would I pull updates from the service, etc. I think I have a fairly good sense of what will work and what will cause headaches. I think I've posted to mailman-i18n@ before about my thoughts there. I'm CC'ing that list here too.
But in some sense, it's more important for the translators to feel comfortable and welcome in whatever system we chose. Most are non-technical, so I think it's easier for us to make project workflow conform to a great translation system's quirks (and there *will* be quirks ;) than for them to work around pain in a translation system that easily integrates with our workflow.
One question I have, and Steve, you're probably a great person to weigh in on this: what requirements does the GPLv3+ and being a GNU project place on us?
Cheers, -Barry
Hi Aside of the actual translations being done... Can someone confirm that german umlauts and more or less exotic characters should work within the mail templates? Or shall i write a bug report? Peter
On 22.08.2012, at 01:47, Barry Warsaw <barry@list.org> wrote:
On Aug 21, 2012, at 01:04 PM, Stephen J. Turnbull wrote:
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she thinks?
Right, that would be Clytie, CC'd here. However, it's been a while since we've heard from her.
There are also active translation communities at Debian and Launchpad, and I would assume at Red Hat/Fedora. Both Deb and Ubuntu are happy Mailman users, and I would guess Red Hat/Fedora, too. All probably would find some of the MM3 features very attractive for their own use.
Definitely, and I've looked at all of the various translation services, mostly from the point of view of a project manager non-translator. E.g. how would I push updates into the service, how would I pull updates from the service, etc. I think I have a fairly good sense of what will work and what will cause headaches. I think I've posted to mailman-i18n@ before about my thoughts there. I'm CC'ing that list here too.
But in some sense, it's more important for the translators to feel comfortable and welcome in whatever system we chose. Most are non-technical, so I think it's easier for us to make project workflow conform to a great translation system's quirks (and there *will* be quirks ;) than for them to work around pain in a translation system that easily integrates with our workflow.
One question I have, and Steve, you're probably a great person to weigh in on this: what requirements does the GPLv3+ and being a GNU project place on us?
Cheers, -Barry
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/devlists%40irrtum....
Security Policy: http://wiki.list.org/x/QIA9
Peter Holzer wrote:
Hi Aside of the actual translations being done... Can someone confirm that german umlauts and more or less exotic characters should work within the mail templates?
Templates for web pages or pieces of web pages should have all non-ascii characters encoded as HTML entities, e.g. 'ä', 'ö', etc.
Text templates for email messages, etc. can have non-ascii (exotic) characters as long as they are encoded in the character set that Mailman uses for that language. For Mailman 2.1 and German, this is iso-8859-1.
Unfortunately, I'm not sure how this is working in MM3 in terms of how the various languages are registered and what the character set for German is (although most should probably be utf-8).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
- Mark Sapiro <mark@msapiro.net>:
Peter Holzer wrote:
Hi Aside of the actual translations being done... Can someone confirm that german umlauts and more or less exotic characters should work within the mail templates?
Templates for web pages or pieces of web pages should have all non-ascii characters encoded as HTML entities, e.g. 'ä', 'ö', etc.
Seriously? Is there a particular reason we can't go UTF-8 and use 'ä', 'ö' the way they are written natively? Don't take it personal, Mark, but eversince I've been on the Internet I had to use a charset from a foreign language to create a crippled representation of my native language. If there's a chance to improve that I'd like to take it.
Text templates for email messages, etc. can have non-ascii (exotic) characters as long as they are encoded in the character set that Mailman uses for that language. For Mailman 2.1 and German, this is iso-8859-1.
Unfortunately, I'm not sure how this is working in MM3 in terms of how the various languages are registered and what the character set for German is (although most should probably be utf-8).
For German most people nowadays use UTF-8.
p@rick
-- state of mind ()
Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
On 8/26/2012 2:12 PM, Patrick Ben Koetter wrote:
- Mark Sapiro <mark@msapiro.net>:
Templates for web pages or pieces of web pages should have all non-ascii characters encoded as HTML entities, e.g. 'ä', 'ö', etc.
Seriously? Is there a particular reason we can't go UTF-8 and use 'ä', 'ö' the way they are written natively?
Yes, there is a reason. HTML entities are a standard way of representing non-ascii characters in HTML that survives miscommunication of character set information between web applications, web servers and web browsers.
Mailman is developed as much as possible to work on multiple servers operated by different people with different configurations. It is possible to configure web servers to include a Content-Type: header with a charset parameter when sending a text/html response which will override the charset parameter in the Content-Type: that Mailman puts in a META tag in the HTML. (See, e.g., <http://httpd.apache.org/docs/2.2/mod/core.html#adddefaultcharset>).
If mailman generates web pages with non-ascii, say utf-8 encoded characters and the installation's web server assigns a default character set other than utf-8, all the utf-8 encoded characters will be garbled. This will not happen if the characters are encoded as HTML entities.
I know you wouldn't do such a thing, but if such a thing is possible, some Mailman installations somewhere will do it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
If mailman generates web pages with non-ascii, say utf-8 encoded characters and the installation's web server assigns a default character set other than utf-8, all the utf-8 encoded characters will be garbled. This will not happen if the characters are encoded as HTML entities.
So have Mailman do the encoding. Mandate that the input data such as templates are UTF-8, that template writers are responsible for ensuring that entities (eg, &) are syntactically correct (they will not be HTML-escaped), the output HTML pages are ASCII, and have Mailman do the translation of non-ASCII to HTML entities. Patrick gets what he wants, Mailman's generated pages are robust to webservers with broken encoding configs, and it is simple to check whether a user has done something stupid like encode their templates in Windows-1252.
Note that this can be done algorithmically by using the horribly ugly Unicode "entities", and the extension to prettier named entities is easy.
You could even provide a config option to turn off HTML escaping (defaulting to escaping on). If somebody has the skills to look at HTML source in a browser and cares, they probably have the skills to configure a webserver properly.
Steve
G'day all :)
On 22/08/2012, at 9:17 AM, Barry Warsaw <barry@list.org> wrote:
On Aug 21, 2012, at 01:04 PM, Stephen J. Turnbull wrote:
Patrick Ben Koetter writes:
They have free accounts for open source projects. It might be a nice way to organize a translation community.
It's likely that we don't have to organize one, we already have one. Barry, why don't you try to get in touch with that Vietnamese lady and see what she thinks?
Right, that would be Clytie, CC'd here. However, it's been a while since we've heard from her.
Unfortunately, I've become too ill to participate usefully (I've had to unsub from or go nomail on my lists). However, I can offer an opinion on the days when I can answer CC'd or direct mail.
There are also active translation communities at Debian and Launchpad, and I would assume at Red Hat/Fedora. Both Deb and Ubuntu are happy Mailman users, and I would guess Red Hat/Fedora, too. All probably would find some of the MM3 features very attractive for their own use.
Definitely, and I've looked at all of the various translation services, mostly from the point of view of a project manager non-translator. E.g. how would I push updates into the service, how would I pull updates from the service, etc. I think I have a fairly good sense of what will work and what will cause headaches. I think I've posted to mailman-i18n@ before about my thoughts there. I'm CC'ing that list here too.
But in some sense, it's more important for the translators to feel comfortable and welcome in whatever system we chose. Most are non-technical, so I think it's easier for us to make project workflow conform to a great translation system's quirks (and there *will* be quirks ;) than for them to work around pain in a translation system that easily integrates with our workflow.
One question I have, and Steve, you're probably a great person to weigh in on this: what requirements does the GPLv3+ and being a GNU project place on us?
Barry, you are spot on with your statement that an effective translation workflow needs to suit the needs and backgrounds of the localizers, not the quirks of the software dev. system. The word "quirks" fits some systems quite well, the egregious example being OpenOffice.org, which has a labyrinthine and migraine-inducing endurance crawl thinly disguised as localization. When I started at OOo, there was no basic howto on how to get through this maze of requirements, so I wrote one. The need for one seemed to come as a surprise to the project hierarchy.
The thing to remember is that localizers usually don't read English with any degree of comfort. You need a simple, step-by-step description of how to get from an unlocalized package to a localized release. Diagrams (e.g. flow charts) are good. Make it a checklist, so they can check off each step.
Have a single login to access all the processes needed for localization. OOo required a huge number of separate logins, each with its own cumbersome procedure. I've often seen localizers shy away from reporting bugs or joining a tracker to submit translations as an issue, because it's one more thing they have to understand and do in a second language.
Login access should also show translation stats, both software and docs (see GNOME's platform for localization), and you should be able to submit translations there. GNOME have done a lot of work on this, so they're good people to ask.
Without more info, I'm assuming from this email that you're looking at integrating Mailman with the main translation projects. In my cross-project experience, Debian i18n have the best record for innovation and quality: see Christian Perrier (CC'd). Debian does use email for submitting localizations and for notifications about them, both actions I assume would be part of your integration. Packages can also use an automatic email localization-update-request process.
You could also look at working with the Translation Project (GNU and others) 's email robot input-and-error-notification process.
When I last used it, (free-software localization interface) Pootle didn't have email integration (although it was one of the features I think I requested ;) ). I think you'd find the Pootle project quite interested in working with you. I found them innovative, flexible and focussed on improving access to localization. (CC'd to their list, in the hope that I went nomail there rather than unsubbed.)
Launchpad used to be insecure and of low quality, but that was a while back. I hear they've improved. They do integrate mailing lists associated with the localization, if supplied.
I could be quite off-base in my response, since I'm not sure from your text what you want to do. ;)
However, when considering localization projects and workflow, for those of you who speak a second language, imagine what would help _you_ if people wanted to encourage you to code for a project where all info and communication is in that second language.
Think about it.
from Clytie
Clytie Siddall Renmark, in the Riverland of South Australia
Clytie Siddall, 27/08/2012 10:07:
G'day all :)
Good morning and thank you for your interesting email.
Barry, you are spot on with your statement that an effective translation workflow needs to suit the needs and backgrounds of the localizers, not the quirks of the software dev. system.
I'm only a lurker on this mailing list but this encouraged me to briefly mention my experience as translator on translatewiki.net (<https://translatewiki.net/wiki/User:Nemo_bis>).
The word "quirks" fits some systems quite well, the egregious example being OpenOffice.org, which has a labyrinthine and migraine-inducing endurance crawl thinly disguised as localization. When I started at OOo, there was no basic howto on how to get through this maze of requirements, so I wrote one. The need for one seemed to come as a surprise to the project hierarchy.
The thing to remember is that localizers usually don't read English with any degree of comfort. You need a simple, step-by-step description of how to get from an unlocalized package to a localized release. Diagrams (e.g. flow charts) are good. Make it a checklist, so they can check off each step.
The good thing of translatewiki.net is that there isn't any step after registration: you only translate, not waste time on process and bureaucracy as on most translation projects. Niklas explains it here for instance: <https://www.youtube.com/watch?v=tqS3YSKfJqU&t=29m1s> Even for registering there's a wizard <https://translatewiki.net/wiki/Special:FirstSteps>
Have a single login to access all the processes needed for localization. OOo required a huge number of separate logins, each with its own cumbersome procedure. I've often seen localizers shy away from reporting bugs or joining a tracker to submit translations as an issue, because it's one more thing they have to understand and do in a second language.
Translatewiki.net has a single login for all projects.
Login access should also show translation stats, both software and docs (see GNOME's platform for localization), and you should be able to submit translations there. GNOME have done a lot of work on this, so they're good people to ask.
Translate has plenty of live statistics. <https://www.mediawiki.org/wiki/Help:Extension:Translate/Statistics_and_repor...>
Without more info, I'm assuming from this email that you're looking at integrating Mailman with the main translation projects. In my cross-project experience, Debian i18n have the best record for innovation and quality: see Christian Perrier (CC'd). Debian does use email for submitting localizations and for notifications about them, both actions I assume would be part of your integration. Packages can also use an automatic email localization-update-request process.
I don't know what you mean exactly with "email integration" and notifications are usually not needed on translatewiki.net to get stuff translated (because translating is easier and there are more translators), anyway <https://www.mediawiki.org/wiki/Extension:TranslationNotifications#Special_pa...> exists and proved very effective on meta.wikimedia.org.
You could also look at working with the Translation Project (GNU and others) 's email robot input-and-error-notification process.
Again, I don't know what a "input-and-error-notification process" but translators on translatewiki.net don't usually have to care about such things (the web interface is reliable enough) and for the few failures there are automatic warnings and aids. <https://www.mediawiki.org/wiki/Help:Extension:Translate#Features>
When I last used it, (free-software localization interface) Pootle didn't have email integration (although it was one of the features I think I requested ;) ). I think you'd find the Pootle project quite interested in working with you. I found them innovative, flexible and focussed on improving access to localization. (CC'd to their list, in the hope that I went nomail there rather than unsubbed.)
Launchpad used to be insecure and of low quality, but that was a while back. I hear they've improved. They do integrate mailing lists associated with the localization, if supplied.
I could be quite off-base in my response, since I'm not sure from your text what you want to do. ;)
However, when considering localization projects and workflow, for those of you who speak a second language, imagine what would help _you_ if people wanted to encourage you to code for a project where all info and communication is in that second language.
And finally, the best feature of translatewiki.net is that its main developers/managers are among the most active translators to their language and this helps a lot, I found.
Federico aka Nemo
participants (7)
-
Barry Warsaw -
Clytie Siddall -
Federico Leva (Nemo) -
Mark Sapiro -
Patrick Ben Koetter -
Peter Holzer -
Stephen J. Turnbull