Pootle and Zanata trial
Hello, team Pootle and Zanata trial are ready for test. 1. Pootle http://23.253.231.198/projects/ 2. Zanata http://15.126.226.230:8080/ I need volunteers to test features and feed back how satisfied you feel. I use an Etherpad page to track: https://etherpad.openstack.org/p/translation-tools-comparation I have gotten volunteers from Korean and Indian team. I'm looking for volunteers from other translation teams. If you want to help, please let me know. If you want to try admin features, send me emails with your account ID. Thank you. Best regards Ying Chun Guo (Daisy)
On 10/16/2014 11:04 AM, Ying Chun Guo wrote:
Great!
I have gotten volunteers from Korean and Indian team. I'm looking for volunteers from other translation teams.
I'd like to test the admin site - do I just sign up or do you need to create an account for me?
If you want to help, please let me know. If you want to try admin features, send me emails with your account ID.
I suggest that you decide before the Paris summit which tool you prefer so that translation and infra teams can plan the next steps face to face, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Andreas Jaeger <aj@suse.com> wrote on 2014/10/16 17:34:36:
You sign up, and tell me your account. I could make you the admin. Could you also take a look at the synchronization mechanism? If we move to one of them, we need to decide whether to use the tool provided update mechanism, or integrate with our existing download & upload scripts.
I've just did a first investigation into the synchronization features - and have a couple of questions regarding the clients: Pootle: - has no official client, there's one in development but it has not seen any changes since over a year https://github.com/translate/pootle-client - it looks abandoned ;( See also http://pootle.readthedocs.org/en/latest/api/using.html - The integration with a VCS like git is a direct commit to a repository, nothing that would work for us: http://pootle.readthedocs.org/en/latest/features/version_control.html Zanata: + synchronization uses same approach as we use with transifex today, we should be able to use the same proposal scripts as today - Official client is a Java client. ? There's a python client https://github.com/zanata/zanata-python-client available as well, not sure about its status. Who can clarify? Has anybody more information? With my current knowledge about pootle, I see no nice way to integrate it into our workflow. I'll test the zanata CLIs next, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi Andreas, First, let me apologize in advance if it seems as if I'm not getting to your emails soon enough, but being in Australia your emails reach me mostly outside of office hours. I will try to keep an eye out for urgent ones though. As for your questions, Zanata's official client is the Java client as it contains the latest and greatest features. Having said that, we also try to keep the python client as up-to-date as possible, but it might be missing some of the latest features that we've added. The reason for this is that we also maintain a Maven client (for software Java projects) and it's based on the same codebase. Contributions are welcome :) As for integration, you can use the client(s), or you can directly call Zanata's Rest API. Documentation on the available endpoints is here: https://zanata.ci.cloudbees.com/job/zanata-api-site/site/zanata-common-api/r... (You can find this link on www.zanata.org under the "Development" section) As always, we're open to any questions you may have when making your decision. Regards, Carlos A. Munoz Software Engineering Supervisor Engineering - Internationalization Red Hat ----- Original Message ----- From: "Andreas Jaeger" <aj@suse.com> To: "Ying Chun Guo" <guoyingc@cn.ibm.com>, openstack-i18n@lists.openstack.org, openstack-infra@lists.openstack.org Sent: Monday, October 20, 2014 5:22:59 PM Subject: Re: [OpenStack-Infra] [Openstack-i18n] Pootle and Zanata trial I've just did a first investigation into the synchronization features - and have a couple of questions regarding the clients: Pootle: - has no official client, there's one in development but it has not seen any changes since over a year https://github.com/translate/pootle-client - it looks abandoned ;( See also http://pootle.readthedocs.org/en/latest/api/using.html - The integration with a VCS like git is a direct commit to a repository, nothing that would work for us: http://pootle.readthedocs.org/en/latest/features/version_control.html Zanata: + synchronization uses same approach as we use with transifex today, we should be able to use the same proposal scripts as today - Official client is a Java client. ? There's a python client https://github.com/zanata/zanata-python-client available as well, not sure about its status. Who can clarify? Has anybody more information? With my current knowledge about pootle, I see no nice way to integrate it into our workflow. I'll test the zanata CLIs next, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
I did some testing using the python client and liked that it was modelled after the transifex one in some cases. I've documented what I tried - and where I run into problems: 1) Create API key 2) install zanata python client: $ git clone https://github.com/zanata/zanata-python-client.git 3) Create nova project: $ zanata --url http://15.126.226.230:8080/ project create nova --project-name="OpenStack Nova" --project-desc="OpenStack Nova" 4) Create project version "master": $ zanata version create master --project-id=nova --version-name=master --version-desc="git master" 5) Manually download zanata.xml file and save to nova top-dir Note this is a manual update, it needs to be kept in the repo. We could create this manually if needed but there's no "tx init" equivalent. 6) Push source po files: $ zanata po push 7) Push translation files: $ zanata --url http://15.126.226.230:8080/ push --push-type=both --transdir=nova/locale/ --lang=fr -f Does not work, it does not find the po files like nova/locale/fr/LC_MESSAGES/nova.po. Questions: * (ad 7): How can I upload the translation files via command line for an initial import? * (ad 5) What happens if more languages get added on the server, how to update the local zanata.xml file? Or is there a way to download it automatically using the client? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi Andreas, The reason why the python client doesn't find your PO files is because it is expecting them to be in a strictly standard place for po files. Because you have that LC_MESSAGES directory, that throws the python client off base. This is one of the things we have improved in our java client. So I'm going to guide you through the same exact steps you are trying here, but with the java client. 1. I cloned the nova source code from https://github.com/openstack/nova/ to start from scratch. 2. I installed the Java client. Of course you need java installed, and then follow the instructions here: https://github.com/zanata/zanata-client-ivy (not sure what you are running on, but the "other systems" section works everywhere) 3. Opened a command line terminal on the nova directory for my checked out project from GitHub and typed $ <PATH-TO-CLI>/zanata-cli init This will guide you through a series of questions to get your project set up (things like where your source files are, etc.). For more information on this you can go to http://zanata.org/help/cli/cli-init/ After this step, your directory should be ready to push source files, which you can do with: $ <PATH-TO-CLI>/zanata-cli push 4. Because of the LC_MESSAGES directory, you need to customize zanata.xml to tell the client where to find translation files. Currently this is a manual step as to be as flexible as possible. For the nova project, I added the following snippet to zanata.xml: <rules> <rule pattern="**/*.pot">{locale_with_underscore}/LC_MESSAGES/{filename}.po</rule> </rules> For more information on why/how to configure your mappings, please refer to http://zanata.org/help/cli/cli-configuration/ , see the "translation files mapping rules" section 5. Pushed the translations files $ <PATH_TO_CLI?zanata-cli push --push-type trans You can view the results on Zanata, for the two locales you had activated. I am attaching the exact zanata.xml that I used. You can use the same zanata.xml to pull your project, or you can follow these steps and it will yield the same result. =============================================================== Now, to answer your specific questions at the end: * (ad 7): How can I upload the translation files via command line for an initial import? I think I covered that in my series of steps above, as it was really an initial push from the source repo. Let me know if you still have questions there. * (ad 5) What happens if more languages get added on the server, how to update the local zanata.xml file? Or is there a way to download it automatically using the client? That is currently a manual process because the server doesn't contain all the information that you might have customized (like I did in my example) in your zanata.xml. Having said that, it should not be very difficult to implement a client feature that lets you update the languages from the project in Zanata. I hope I've shed some light on the zanata client workings. As usual, let me know if you have any other questions. Regards, Carlos A. Munoz Software Engineering Supervisor Engineering - Internationalization Red Hat On 10/22/2014 09:42 PM, Andreas Jaeger wrote:
On 10/23/2014 03:01 AM, Carlos Munoz wrote:
Thanks! So, the question is whether this gets fixed in the python client - or whether we should use the java client...
[...]
No, looks fine.
Yes, with our workflow this is needed. Do you have a proposal for a better workflow than the one we're using? What are others doing?
I hope I've shed some light on the zanata client workings. As usual, let me know if you have any other questions.
-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
My personal recommendation is to use the Java client, at least to begin with. I know it isn't as easy to install as a pure python client, but it does offer far more functionality and flexibility. Installation is a one-time thing, and once it's up and running there's no need to change it. The main maintainer for the python client is another Red Hatter outside of our core team; I can put you in contact with him as well so he can answer some questions and maybe start adapting some of the newer features to the python client. In terms of workflow (and I must admit I'm not all that familiar with yours), most projects simply keep their zanata.xml in the source repos and update manually, but in most cases adding or removing languages is very infrequent. I have created a bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1156236) so we can get the conversation started on auto-updating those language codes. Regards, Carlos Carlos A. Munoz Software Engineering Supervisor Engineering - Internationalization Red Hat ----- Original Message ----- From: "Andreas Jaeger" <aj@suse.com> To: camunoz@redhat.com Cc: openstack-i18n@lists.openstack.org, openstack-infra@lists.openstack.org Sent: Thursday, October 23, 2014 9:58:23 PM Subject: Re: [Openstack-i18n] [OpenStack-Infra] Pootle and Zanata trial On 10/23/2014 03:01 AM, Carlos Munoz wrote:
Thanks! So, the question is whether this gets fixed in the python client - or whether we should use the java client...
[...]
No, looks fine.
Yes, with our workflow this is needed. Do you have a proposal for a better workflow than the one we're using? What are others doing?
I hope I've shed some light on the zanata client workings. As usual, let me know if you have any other questions.
-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On 10/24/2014 01:43 AM, Carlos Munoz wrote:
My personal recommendation is to use the Java client, at least to begin with. I know it isn't as easy to install as a pure python client, but it does offer far more functionality and flexibility. Installation is a one-time thing, and once it's up and running there's no need to change it. The main maintainer for the python client is another Red Hatter outside of our core team; I can put you in contact with him as well so he can answer some questions and maybe start adapting some of the newer features to the python client.
With our CI infrastructure, where we have virtual machines that we start up for each job, we either would need to add the client to our own images and integrate them so that whenever we generate a new image, it keeps included - or install it whenever we start.
In terms of workflow (and I must admit I'm not all that familiar with yours), most projects simply keep their zanata.xml in the source repos and update manually, but in most cases adding or removing languages is very infrequent. I have created a bugzilla (https://bugzilla.redhat.com/show_bug.cgi?id=1156236) so we can get the conversation started on auto-updating those language codes.
thanks! Andreas
-- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
On Mon, Oct 20, 2014 at 12:22 AM, Andreas Jaeger <aj@suse.com> wrote:
I'll go ahead and forward these questions on to the developer at Pootle who has been helping us out. Thanks for looking into this. -- Elizabeth Krumbach Joseph || Lyz || pleia2
participants (4)
-
Andreas Jaeger
-
Carlos Munoz
-
Elizabeth K. Joseph
-
Ying Chun Guo