Re: proposal for new l10n workflow
On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. We should avoid confusion here, the new process is under development yet but not available yet. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: proposal for new l10n workflow
I just double checked: the pointer is: Localization AOOhttp://wiki.openoffice.org/wiki/Localization_AOO, which clearly stated (the very first lines of the document) This document is based on and extents Localization_for_developershttp://wiki.openoffice.org/wiki/Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developershttp://wiki.openoffice.org/wiki/Localization_for_developers . But I will happely remove it if you prefer, but then where do I put a link to the more detailed description of the CURRENT process. jan. On 30 October 2012 13:30, jan iversen jancasacon...@gmail.com wrote: I am guilty. see below. On 30 October 2012 13:22, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. The page it points to, is NOT the new proposal, that would be wrong, but the first I made with a more detailed description of how it works today. I hope that is ok ? We should avoid confusion here, the new process is under development yet but not available yet. I totally agree, and I have not made links that suggest otherwise. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: proposal for new l10n workflow
On 10/30/12 1:33 PM, jan iversen wrote: I just double checked: the pointer is: Localization AOOhttp://wiki.openoffice.org/wiki/Localization_AOO, which clearly stated (the very first lines of the document) This document is based on and extents Localization_for_developershttp://wiki.openoffice.org/wiki/Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developershttp://wiki.openoffice.org/wiki/Localization_for_developers . I simply missed some basic info how the tools have to be used etc.. I was confused... But I will happely remove it if you prefer, but then where do I put a link to the more detailed description of the CURRENT process. no need to remove it now, I know whats behind and as long as nobody delete it I am fine Juergen jan. On 30 October 2012 13:30, jan iversen jancasacon...@gmail.com wrote: I am guilty. see below. On 30 October 2012 13:22, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. The page it points to, is NOT the new proposal, that would be wrong, but the first I made with a more detailed description of how it works today. I hope that is ok ? We should avoid confusion here, the new process is under development yet but not available yet. I totally agree, and I have not made links that suggest otherwise. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: proposal for new l10n workflow
If my page needs updating, feel free to do so, I actually copied all the scripts things from the other page. jan. On 30 October 2012 14:28, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 1:33 PM, jan iversen wrote: I just double checked: the pointer is: Localization AOOhttp://wiki.openoffice.org/wiki/Localization_AOO, which clearly stated (the very first lines of the document) This document is based on and extents Localization_for_developers http://wiki.openoffice.org/wiki/Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developers http://wiki.openoffice.org/wiki/Localization_for_developers . I simply missed some basic info how the tools have to be used etc.. I was confused... But I will happely remove it if you prefer, but then where do I put a link to the more detailed description of the CURRENT process. no need to remove it now, I know whats behind and as long as nobody delete it I am fine Juergen jan. On 30 October 2012 13:30, jan iversen jancasacon...@gmail.com wrote: I am guilty. see below. On 30 October 2012 13:22, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. The page it points to, is NOT the new proposal, that would be wrong, but the first I made with a more detailed description of how it works today. I hope that is ok ? We should avoid confusion here, the new process is under development yet but not available yet. I totally agree, and I have not made links that suggest otherwise. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: proposal for new l10n workflow
On 10/30/12 2:45 PM, jan iversen wrote: If my page needs updating, feel free to do so, I actually copied all the scripts things from the other page. I see it now, I must have been blind earlier, sorry for the confusion Juergen jan. On 30 October 2012 14:28, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/30/12 1:33 PM, jan iversen wrote: I just double checked: the pointer is: Localization AOOhttp://wiki.openoffice.org/wiki/Localization_AOO, which clearly stated (the very first lines of the document) This document is based on and extents Localization_for_developers http://wiki.openoffice.org/wiki/Localization_for_developers. The document is work in progress showing the result of a detailed technical analysis of the current process (version 3.4.1) . As such this document should be seen as a replacement of Localization_for_developers http://wiki.openoffice.org/wiki/Localization_for_developers . I simply missed some basic info how the tools have to be used etc.. I was confused... But I will happely remove it if you prefer, but then where do I put a link to the more detailed description of the CURRENT process. no need to remove it now, I know whats behind and as long as nobody delete it I am fine Juergen jan. On 30 October 2012 13:30, jan iversen jancasacon...@gmail.com wrote: I am guilty. see below. On 30 October 2012 13:22, Jürgen Schmidt jogischm...@gmail.com wrote: On 10/27/12 10:51 PM, jan iversen wrote: Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. I noticed that somebody put an outdated template on http://wiki.openoffice.org/wiki/Localization_for_developers which I think is a little bit early. The new page is a great resource to discuss a new workflow and necessary improvements. But the currently Localization for developers page describes how it works today. The page it points to, is NOT the new proposal, that would be wrong, but the first I made with a more detailed description of how it works today. I hope that is ok ? We should avoid confusion here, the new process is under development yet but not available yet. I totally agree, and I have not made links that suggest otherwise. Juergen Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I.
Re: proposal for new l10n workflow
Based on the comments I have received, I have updated the document. The major changes are: - removed l10n web page tools - no auto-commit in any tools - proposed changes to pootle server (based on request from andrea, to use/change existing tools) - added more text on the translation workflow, inkl. local teams The document is available as pdf: http://wiki.openoffice.org/wiki/File:L10procNew2.pdf and (due to a polite hint) as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/new_proposal Furthermore a projectplan is available as a wiki page: http://wiki.openoffice.org/wiki/Localization_AOO/workPlan this mail is posted on both ooo-L10n and ooo-dev, but please use ooo-dev for discussions. Andrea: I hope you have time to see if your suggestions are well represented now, so this document could be used as discussion basis when you meet the pootle people. Have a nice evening. jan I. On 25 October 2012 23:01, Andrea Pescetti pesce...@apache.org wrote: On 21/10/2012 jan iversen wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/**wiki/File:L10procNew.pdfhttp://wiki.openoffice.org/wiki/File:L10procNew.pdf It seems I'm the first one who replies after having read your document in full. And the quality of your proposal is not the issue here: on the contrary, it is a very good one and I'm answering in detail below. So the issue must be somewhere else. I'm confident you will understand that I'm not criticizing or lecturing you here, and I'm not implying any of the items below to be you fault (none is); but maybe this will help you in getting better feedback in future. 1) Unfortunate timing. We've just graduated, the Apache Conference is coming in about one week, we need to relocate all infrastructure... It's a busy period, so we may be less responsive than usual. 2) Excess of communication. If all people on this list had written as much as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have received a message every 9 seconds! If you make yourself manageable it will be easier for us to answer your requests with less confusion. 3) Dispersion of communication. Discussion about your proposal is scattered in three different threads across ooo-dev and ooo-l10n (not counting private e-mails); if you need to send a message to multiple lists, and this is a good example, it's best to send one message to two lists (and specify which one should receive answers) since answers will be grouped in the same discussion for people who are reading e-mail by discussions. 4) Proposal format. Uploading a PDF is very convenient but it does not make others feel empowered to really contribute. I would have applied a dozen typo fixes to your proposal if it had been available as a wiki page. Others might have done the same. OK, enough said. The proposal has significant merit, so let's focus on that for the rest of this message. It won't be short: it's still a 20-page document. The main reasons to drive it forward are: - It puts us back in total control of the l10n process, with no need to rely on partially broken or lost tools. - It reduces the number of steps strings must go through for being translated and imported back. - It automates a number of operations that have been manual so far. - It allows to have a proper version control for translations. In general, I think the document would benefit from some knowledge about how the process works with established teams: - There is a string freeze date in the release schedule (this concept needn't be taken away: for sure we still want a string freeze even if tools allow a continuous localization; translators shouldn't have the surprise to see new strings appear in the last weeks before a release) - After string freeze, strings are made available in Pootle (and this happens automatically in your proposal) - Volunteers pick a file, usually a help file and the main application related to it (so, the sw module for Writer and its help file; and, answering another message from you, the subdivision you propose would be OK). Here indeed it is helpful to know that a file has been taken, something that volunteers track manually at the moment. Volunteers do not have time constraints and may well take two weeks to complete their assignments: the 4 days you propose are not realistic for most teams. - Nobody works on Pootle. This has nothing to do with rights, it is totally incorrect to see Pootle as the committers tool. The Pootle server used to be slow and not responsive and anyway, as a matter of fact, most people, including me, prefer to work with downloaded files. - Volunteers mark all strings they touched as fuzzy to distinguish them; if I understand correctly, a XLIFF based workflow here would suggest to mark the strings as to be reviewed. - Other volunteers (in general one person per language) review the translations, collect all
Re: proposal for new l10n workflow
Thanks a lot for your long and informative answer, I read it with a positive attitude and will just make one comment, it is hard to be new especially with the state of documentation we have. I will in the future make a lot less noise. I will work your comments into my proposal, and in general I agree it is better to extend existing tools than to make new ones. There is however one misunderstanding (probably due to my formulations) that I need to correct, the l10n upload/download feature was NOT to circumvent the system, but to allow contributors to upload files without having to go through private mail adresses/bugzilla etc. Thanks for using time on my proposal. Jan. On 25 October 2012 23:01, Andrea Pescetti pesce...@apache.org wrote: On 21/10/2012 jan iversen wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/**wiki/File:L10procNew.pdfhttp://wiki.openoffice.org/wiki/File:L10procNew.pdf It seems I'm the first one who replies after having read your document in full. And the quality of your proposal is not the issue here: on the contrary, it is a very good one and I'm answering in detail below. So the issue must be somewhere else. I'm confident you will understand that I'm not criticizing or lecturing you here, and I'm not implying any of the items below to be you fault (none is); but maybe this will help you in getting better feedback in future. 1) Unfortunate timing. We've just graduated, the Apache Conference is coming in about one week, we need to relocate all infrastructure... It's a busy period, so we may be less responsive than usual. 2) Excess of communication. If all people on this list had written as much as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have received a message every 9 seconds! If you make yourself manageable it will be easier for us to answer your requests with less confusion. 3) Dispersion of communication. Discussion about your proposal is scattered in three different threads across ooo-dev and ooo-l10n (not counting private e-mails); if you need to send a message to multiple lists, and this is a good example, it's best to send one message to two lists (and specify which one should receive answers) since answers will be grouped in the same discussion for people who are reading e-mail by discussions. 4) Proposal format. Uploading a PDF is very convenient but it does not make others feel empowered to really contribute. I would have applied a dozen typo fixes to your proposal if it had been available as a wiki page. Others might have done the same. OK, enough said. The proposal has significant merit, so let's focus on that for the rest of this message. It won't be short: it's still a 20-page document. The main reasons to drive it forward are: - It puts us back in total control of the l10n process, with no need to rely on partially broken or lost tools. - It reduces the number of steps strings must go through for being translated and imported back. - It automates a number of operations that have been manual so far. - It allows to have a proper version control for translations. In general, I think the document would benefit from some knowledge about how the process works with established teams: - There is a string freeze date in the release schedule (this concept needn't be taken away: for sure we still want a string freeze even if tools allow a continuous localization; translators shouldn't have the surprise to see new strings appear in the last weeks before a release) - After string freeze, strings are made available in Pootle (and this happens automatically in your proposal) - Volunteers pick a file, usually a help file and the main application related to it (so, the sw module for Writer and its help file; and, answering another message from you, the subdivision you propose would be OK). Here indeed it is helpful to know that a file has been taken, something that volunteers track manually at the moment. Volunteers do not have time constraints and may well take two weeks to complete their assignments: the 4 days you propose are not realistic for most teams. - Nobody works on Pootle. This has nothing to do with rights, it is totally incorrect to see Pootle as the committers tool. The Pootle server used to be slow and not responsive and anyway, as a matter of fact, most people, including me, prefer to work with downloaded files. - Volunteers mark all strings they touched as fuzzy to distinguish them; if I understand correctly, a XLIFF based workflow here would suggest to mark the strings as to be reviewed. - Other volunteers (in general one person per language) review the translations, collect all files and make them available to developers (Bugzilla, personal web space, e-mail...) So we already have a (kind of) team coordinator who reviews the files and is a committer. Again: you can assume that we have a person per
Re: proposal for new l10n workflow
On 21/10/2012 jan iversen wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/wiki/File:L10procNew.pdf It seems I'm the first one who replies after having read your document in full. And the quality of your proposal is not the issue here: on the contrary, it is a very good one and I'm answering in detail below. So the issue must be somewhere else. I'm confident you will understand that I'm not criticizing or lecturing you here, and I'm not implying any of the items below to be you fault (none is); but maybe this will help you in getting better feedback in future. 1) Unfortunate timing. We've just graduated, the Apache Conference is coming in about one week, we need to relocate all infrastructure... It's a busy period, so we may be less responsive than usual. 2) Excess of communication. If all people on this list had written as much as you did in the last 24 hours to the OpenOffice lists, ooo-dev would have received a message every 9 seconds! If you make yourself manageable it will be easier for us to answer your requests with less confusion. 3) Dispersion of communication. Discussion about your proposal is scattered in three different threads across ooo-dev and ooo-l10n (not counting private e-mails); if you need to send a message to multiple lists, and this is a good example, it's best to send one message to two lists (and specify which one should receive answers) since answers will be grouped in the same discussion for people who are reading e-mail by discussions. 4) Proposal format. Uploading a PDF is very convenient but it does not make others feel empowered to really contribute. I would have applied a dozen typo fixes to your proposal if it had been available as a wiki page. Others might have done the same. OK, enough said. The proposal has significant merit, so let's focus on that for the rest of this message. It won't be short: it's still a 20-page document. The main reasons to drive it forward are: - It puts us back in total control of the l10n process, with no need to rely on partially broken or lost tools. - It reduces the number of steps strings must go through for being translated and imported back. - It automates a number of operations that have been manual so far. - It allows to have a proper version control for translations. In general, I think the document would benefit from some knowledge about how the process works with established teams: - There is a string freeze date in the release schedule (this concept needn't be taken away: for sure we still want a string freeze even if tools allow a continuous localization; translators shouldn't have the surprise to see new strings appear in the last weeks before a release) - After string freeze, strings are made available in Pootle (and this happens automatically in your proposal) - Volunteers pick a file, usually a help file and the main application related to it (so, the sw module for Writer and its help file; and, answering another message from you, the subdivision you propose would be OK). Here indeed it is helpful to know that a file has been taken, something that volunteers track manually at the moment. Volunteers do not have time constraints and may well take two weeks to complete their assignments: the 4 days you propose are not realistic for most teams. - Nobody works on Pootle. This has nothing to do with rights, it is totally incorrect to see Pootle as the committers tool. The Pootle server used to be slow and not responsive and anyway, as a matter of fact, most people, including me, prefer to work with downloaded files. - Volunteers mark all strings they touched as fuzzy to distinguish them; if I understand correctly, a XLIFF based workflow here would suggest to mark the strings as to be reviewed. - Other volunteers (in general one person per language) review the translations, collect all files and make them available to developers (Bugzilla, personal web space, e-mail...) So we already have a (kind of) team coordinator who reviews the files and is a committer. Again: you can assume that we have a person per language who is a committer (new languages go through a brief transition phase, but as you probably understood from the 20-30 daily answers you receive from committers, we try to be rather active in mentoring and helping in this transition phase). Now I don't see the need for the web application you propose for l10n.openoffice.org. It seems a way to circumvent the policy in order to allow non-committers to do something that committers can do: but if the policy is problematic, we'd rather discuss and change it than building tools to circumvent it. And, under the assumption that for each language we have a reviewer/committer, I would just use the Pootle functions for that. Pootle already offers: download, upload, visual representation of translation progress, integration with version control (but
Re: proposal for new l10n workflow
On Sun, Oct 21, 2012 at 12:14 PM, jan iversen jancasacon...@gmail.com wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/wiki/File:L10procNew.pdf I'll take a closer look, but I did browse it quickly and had one question: Do we know more about what it means to have Pootle access Subversion? Does this need read/write access? If so, what SVN account is it using? Is it using credentials from the current logged in Pootle user? Does it need to store SVN login credentials? Since Pootle and SVN are both ASF-wide services, managed by the Infrastructure team, we'll need to coordinate this carefully. Security concerns will weigh heavily on what is possible here. -Rob I have tried to implement the comments (on the document describing the existing workflow) from the community, and at the same time avoid non-essential themes that seems to open discussions :-) The workflow I have proposed is based on my knowledge from large organizations, so I am sure it can workbut I do not know if the community as such want it. It has advantages for everybody: - developers dont really see a change - our release manager saves a lot of manual work - offline translators become a lot closer connected to the process, without being bugged down with technical details. My shoulders are pretty big, so please give me your opinions and suggestions for improvement (I am here to learn, NOT to educate). Please remember one thing the big silent majority does not count here. I post this mail here to give developers a change to speak their mind, it is also posted on l10n, for the more translators who are of course heavily influenced. Once we have agreed to the content, I will undertake the development, but I do need heavy support from a committer (mostly to commit code and publish php/web pages). happy reading. JanI
Re: proposal for new l10n workflow
On 22 October 2012 00:01, Rob Weir robw...@apache.org wrote: On Sun, Oct 21, 2012 at 12:14 PM, jan iversen jancasacon...@gmail.com wrote: I have finally finished my proposal for a new workflow. please have a look at: http://wiki.openoffice.org/wiki/File:L10procNew.pdf I'll take a closer look, but I did browse it quickly and had one question: Hope you like what you read. Do we know more about what it means to have Pootle access Subversion? Does this need read/write access? If so, what SVN account is it using? Is it using credentials from the current logged in Pootle user? Does it need to store SVN login credentials? According to the home page (I have no personal experience) will pootle use the account you use on pootle Yes it requires read/write access, otherwise you cannot commit your changes, and would again have manual steps. Andrea told me that you might meet the developer 4-5 november. Since Pootle and SVN are both ASF-wide services, managed by the Infrastructure team, we'll need to coordinate this carefully. Security concerns will weigh heavily on what is possible here. I totally agree, but the real question is: how many are using pootle to translate compared to the total number. Everybody have been telling me, that most translation is done offline..so that is where I have put my emphasis. -Rob I have tried to implement the comments (on the document describing the existing workflow) from the community, and at the same time avoid non-essential themes that seems to open discussions :-) The workflow I have proposed is based on my knowledge from large organizations, so I am sure it can workbut I do not know if the community as such want it. It has advantages for everybody: - developers dont really see a change - our release manager saves a lot of manual work - offline translators become a lot closer connected to the process, without being bugged down with technical details. My shoulders are pretty big, so please give me your opinions and suggestions for improvement (I am here to learn, NOT to educate). Please remember one thing the big silent majority does not count here. I post this mail here to give developers a change to speak their mind, it is also posted on l10n, for the more translators who are of course heavily influenced. Once we have agreed to the content, I will undertake the development, but I do need heavy support from a committer (mostly to commit code and publish php/web pages). happy reading. JanI
