Re: [Openstack] Proposal for manuals translation process
Hi, Anne Thank you for your comments. I'm glad to know that you are working for a larger "goal". I don't know Launchpad is broken with code strings now. What do you mean when you said "Launchpad to be broken with code strings now"? I take a look at Horizon in Transifex. Gabriel Hurley is the coordinator. Can I know the reason why Dashboard turn to Transifex other than Launchpad? Pootle will be a good open source project to look into. It supports a very powerful "Terminology matching" feature, which can match and list the relevant terminologies at real time. The translation memory feature is not so powerful. Suggested translations from a translation memory must be generated before translation, while Transifex can list suggested translations at real time. I will add the third column in our wiki page. There is a major issue for Pootle that we need to consider. Although Pootle has its official server to host the translation of Pootle UI and related projects, the policy for selecting projects on our official server are not finalised yet. I cannot find a way to register our projects in that official server. So we might need to host our own Pootle server if we use it. Are we able to host our own translation server? I'm not clear whether Pootle supports OpenID. If we are going to host our own Pootle server, maybe we can enhance it and enable the OpenID authentication. Both Launchpad and Transifex, even Pootle, manage the translation review process by their own. I think, the translation quality review shall be done using the translation tool. Gerrit and Jenkins will play an important role in Generating step. I'm not familiar with Gerrit and Jenkins. If my description is wrong, feel free to correct me. After the fourth step "Converging", DocBooks in different languages will be generated and submitted to Gerrit for review. Jenkins will run Maven build and upload the generated sources to server. The reviewer ( translation coordinator ) will accept the changes. When I propose the five steps, I only think of manuals translation. Code strings may be a little different. Are there any globalization test in Jenkins? If there is no, we may need to add globalization test. Regards Daisy annegen...@justwriteclick.com wrote on 04/28/2012 03:21:07 AM: > Anne Gentle > Sent by: annegen...@justwriteclick.com > > 04/28/2012 03:21 AM > > To > > Ying Chun Guo/China/IBM@IBMCN, > > cc > > openstack@lists.launchpad.net > > Subject > > Re: [Openstack] Proposal for manuals translation process > > Hi Daisy, > > Thanks so much for this detailed proposal. I'd like you to put it on > the OpenStack wiki, at http://wiki.openstack.org/Translations. > > My first read-through and discussion with the CI team brings up a > few comments: > - Whatever we do for docs, we should also do for code strings. So > unfortunately the scope for the "Goal" probably cannot be so narrow. > We know Launchpad to be broken with code strings now, that data > point should be reflected in this point-in-time analysis. > > - Dashboard uses Transifex now (while the other projects > unsuccessfully use Launchpad). Tres Henry, can you comment on the > number of translators of Dashboard strings you have on the Transifex > side already? > > - Not that I want analysis paralysis, but, we may need to add a > third column of a crowd-sourced translation option like Pootle that > is familiar to open-source translators. Also, the lack of a > translation memory/dictionary (and having to hold such a valuable > asset in a wiki page) is troubling, can we also analyze an option > that offers a translation dictionary? So much re-use would be > available to all the projects. > > - There seems to be assumptions that Jenkins and Gerrit will "just > work" with out much description of the role those two crucial tools > play. Can you further describe the workflow for those in the > Slicing, Uploading, Downloading, Converging, and Generating steps? > > I appreciate all the hard work I _know_ went into this proposal. > Let's get it on the wiki, discuss more, and keep adding details. I'd > like to make this a blueprint, could be for openstack-manuals, could > be for horizon, I don't know yet. Thanks for stepping up and > embracing our international community's needs! > > Thanks, > Anne > > > > > On Fri, Apr 27, 2012 at 3:45 AM, Ying Chun Guo wrote: > Hi, all > > During the "I18N in OpenStack" discussion in design summit, it is > mentioned that documents need to I18N. I also noticed some requests > for a Chinese version manuals from China users. But unlike Gettext > strings in the codes, there is no process for DocBook translation > yet. Translators, who want to help translatio
Re: [Openstack] Proposal for manuals translation process
Ying Chun Guo wrote: > Thank you for your comments. I'm glad to know that you are working for a > larger "goal". I don't know > Launchpad is broken with code strings now. What do you mean when you > said "Launchpad to be > broken with code strings now "? Actually it's our tooling around that (and more specifically, I believe, the inclusion of translated strings back into code) that is currently broken. Launchpad Translations itself works quite well (and strings are still getting translated there). The question is whether it's worth fixing it, so we must define our objectives with respect to translations first :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for manuals translation process
I agree that we should define our objectives with respect to translations. And we should also define the criteria of the translation web tool. There are three tools mentioned in the community now: Launchpad, Transifex and Pootle. They have their own characteristics. The strength and the shortage are different. Before we start selection, we need to decide the criteria, and the priorities of the required features. How can we start this work? Shall we start by a vote? Regards Ying Chun Guo (Daisy) China Standards and Open Source Team Emerging Technology Institute (ETI) IBM China Development Lab Tel:(86-10)82453491 Email: guoyi...@cn.ibm.com Address: 1F Tower B, Diamond Building 19 Zhongguancun Software Park, 8 Dongbeiwang West Road, Haidian District, Beijing, P.R.C.100193 openstack-bounces+guoyingc=cn.ibm@lists.launchpad.net wrote on 05/02/2012 11:55:59 PM: > Thierry Carrez > Sent by: openstack-bounces+guoyingc=cn.ibm@lists.launchpad.net > > 05/02/2012 11:55 PM > > To > > openstack@lists.launchpad.net, > > cc > > Subject > > Re: [Openstack] Proposal for manuals translation process > > Ying Chun Guo wrote: > > Thank you for your comments. I'm glad to know that you are working for a > > larger "goal". I don't know > > Launchpad is broken with code strings now. What do you mean when you > > said "Launchpad to be > > broken with code strings now "? > > Actually it's our tooling around that (and more specifically, I believe, > the inclusion of translated strings back into code) that is currently > broken. Launchpad Translations itself works quite well (and strings are > still getting translated there). > > The question is whether it's worth fixing it, so we must define our > objectives with respect to translations first :) > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for manuals translation process
Ying Chun Guo wrote: > I agree that we should define our objectives with respect to translations. > And we should also define the criteria of the translation web tool. > There are three > tools mentioned in the community now: Launchpad, Transifex and Pootle. > They have their own characteristics. The strength and the shortage are > different. > Before we start selection, we need to decide the criteria, and the > priorities of the required features. > > How can we start this work? Shall we start by a vote? First I'd like the i18n scope thread to reach some consensus at: https://lists.launchpad.net/openstack/msg10988.html Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for manuals translation process
Hi, Thierry Thank you for response. As I know, Launchpad will automatically make regular commits to a Bazaar branch, exporting MO files. Is that broken? Or, it is your own tool to exports MO files to Github that is broken? How is the workload to fix it? If we are going to use other translation web tool, there is also much workload to customize and install. Daisy openstack-bounces+guoyingc=cn.ibm@lists.launchpad.net wrote on 05/02/2012 11:55:59 PM: > Thierry Carrez > Sent by: openstack-bounces+guoyingc=cn.ibm@lists.launchpad.net > > 05/02/2012 11:55 PM > > To > > openstack@lists.launchpad.net, > > cc > > Subject > > Re: [Openstack] Proposal for manuals translation process > > Ying Chun Guo wrote: > > Thank you for your comments. I'm glad to know that you are working for a > > larger "goal". I don't know > > Launchpad is broken with code strings now. What do you mean when you > > said "Launchpad to be > > broken with code strings now "? > > Actually it's our tooling around that (and more specifically, I believe, > the inclusion of translated strings back into code) that is currently > broken. Launchpad Translations itself works quite well (and strings are > still getting translated there). > > The question is whether it's worth fixing it, so we must define our > objectives with respect to translations first :) > > -- > Thierry Carrez (ttx) > Release Manager, OpenStack > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal for manuals translation process
Hi Daisy, Thanks so much for this detailed proposal. I'd like you to put it on the OpenStack wiki, at http://wiki.openstack.org/Translations. My first read-through and discussion with the CI team brings up a few comments: - Whatever we do for docs, we should also do for code strings. So unfortunately the scope for the "Goal" probably cannot be so narrow. We know Launchpad to be broken with code strings now, that data point should be reflected in this point-in-time analysis. - Dashboard uses Transifex now (while the other projects unsuccessfully use Launchpad). Tres Henry, can you comment on the number of translators of Dashboard strings you have on the Transifex side already? - Not that I want analysis paralysis, but, we may need to add a third column of a crowd-sourced translation option like Pootle that is familiar to open-source translators. Also, the lack of a translation memory/dictionary (and having to hold such a valuable asset in a wiki page) is troubling, can we also analyze an option that offers a translation dictionary? So much re-use would be available to all the projects. - There seems to be assumptions that Jenkins and Gerrit will "just work" with out much description of the role those two crucial tools play. Can you further describe the workflow for those in the Slicing, Uploading, Downloading, Converging, and Generating steps? I appreciate all the hard work I _know_ went into this proposal. Let's get it on the wiki, discuss more, and keep adding details. I'd like to make this a blueprint, could be for openstack-manuals, could be for horizon, I don't know yet. Thanks for stepping up and embracing our international community's needs! Thanks, Anne On Fri, Apr 27, 2012 at 3:45 AM, Ying Chun Guo wrote: > Hi, all > > During the "I18N in OpenStack" discussion in design summit, it is > mentioned that documents need to I18N. I also noticed some requests for a > Chinese version manuals from China users. But unlike Gettext strings in the > codes, there is no process for DocBook translation yet. Translators, who > want to help translation, have to take a DocBook into a tool and perform > a translation on a copy which will be saved as a new file. This > traditional translation model is not good for collaboration. Usually, the > open source translation depends on volunteers. It's better to use the crowd > translation model, which enables a mass of translators to work on the > same job, just like the Launchpad Web UI for Gettext strings translation, > any people can jump in at any time and contribute to any part of the > translatable contents. > > In order to facilitate the manuals translation, I investigated several > translation websites and several open source projects. I composed this > proposal. Now it's open for suggestions and comments. > > *Goal* > ** > A process for manuals translation > > *Background* > *--* > OpenStack Manuals are in DocBook format. The source is on GitHub: > http://github.com/openstack/openstack-manuals > Launchpad and Transifex are free web based tools used for crowd > translation. Both of them provide a simple web interface in which > non-technical people can help translation. They don't support DocBook > format, but support the popular GNU Gettext file formats (PO Template or > PO). > > *Translation Process* > *---* > In order to translate OpenStack Manuals to multiple languages, which are > in DocBook format, we can slice the documents into short statements, then > use a web based translation management tool to manage the translation > process, and finally converge the translated content into a new copy of > DocBook. > > Here are the five steps of the translation process: > Step #1 Slicing - extract translatable content from DocBooks and generate > Gettext compatible POT files (PO Template or PO); > Step #2 Uploading - upload the POT (or PO) files to a web based > translation management tool; > Step #3 Downloading - download PO (or MO) files from the web tool after > translation and review; > Step #4 Converging - converge the translated contents into new copies of > DocBook, create DocBooks in multiple languages > Step #5 Generating - generate HTML/PDF in multiple languages from DocBooks > in multiple languages > > The picture in the attachment describes these steps. > *(See attached file: DocBook translation process.png)* > > *Compare of Launchpad and Transifex* > *---* > Launchpad (https://launchpad.net/) and Transifex ( > https://www.transifex.net/) are similar web based tools used for crowd > translation. The goal of the compare is to find the most appropriate tool > for this scenario. The compare are made between Launchpad and Transifex > free version for open sources. (Refer to https://www.transifex.net/plans/ to > get details of “Transifex free version for open sources”) > > After considering the requirements for manuals translation, below > perspectives are taking into consideration: > *Support
