From: Ying Chun Guo/China/IBM To: Andreas Jaeger <aj@suse.com> Cc: Matt Riedemann <mriedem@linux.vnet.ibm.com>, openstack- i18n@lists.openstack.org Date: 2015/09/25 10:17 Subject: Re: [Openstack-i18n] translating python clients
Andreas Jaeger <aj@suse.com> wrote on 2015/09/23 15:06:56:
From: Andreas Jaeger <aj@suse.com> To: Matt Riedemann <mriedem@linux.vnet.ibm.com>, Ying Chun Guo/ China/IBM@IBMCN Cc: openstack-i18n@lists.openstack.org Date: 2015/09/23 15:07 Subject: Re: [Openstack-i18n] translating python clients
On 2015-09-22 22:53, Matt Riedemann wrote:
On 9/21/2015 10:49 AM, Ying Chun Guo wrote:
Andreas Jaeger <aj@suse.com> wrote on 09/21/2015 10:27:29 PM:
From: Andreas Jaeger <aj@suse.com> To: Matt Riedemann <mriedem@linux.vnet.ibm.com>, openstack- i18n@lists.openstack.org Date: 09/21/2015 10:28 PM Subject: Re: [Openstack-i18n] translating python clients
On 2015-09-21 16:09, Matt Riedemann wrote:
On 9/18/2015 10:54 AM, Akihiro Motoki wrote: > I have no comment on Liberty translation priority atm. > > I think a couple of different topics are discussed at the same
here.
> > * CLI translation priority > * Server side project translation priority > * (potential) usage of server side project translations in
Horizon
> > We need to have more contact with project teams in the next cycle > more deeply to decide translation priorties before starting translations. > In the past releases, i18n team tended to start discussions after > starting > translations and it is too late for the game in most cases. > > Regarding client projects, I know openstackclient is our future and > the keystone team encourage to use openstackclient for Keystone v3 API. > However, regarding other projects like nova or neutron, > the progress of openstackclient integration is not well enojgh > and a new feature is implemented in each client. > Thus we need to consider the priority in the next cycle.
I agree with this. We are nowhere near, as far as I can tell anyway, of deprecating python-novaclient. The reason we pushed the changes to translate the project is because people are pushing changes into python-novaclient to mark strings for translation, but there was never any infrastructure in place to do those translations (the
even configured with babel until a couple of weeks ago).
So the feeling was, why not translate it? It's easy to setup. I agree that python-openstackclient is higher priority for the CLI, but python-novaclient is not going away anytime soon, especially now
have microversion support in it for the compute API, which I don't
wasn't that we think
python-openstackclient has.
But just the setup will not give you translations for free. Even if we set it up, I fear no one will translate it. Therefore I wonder whether it makes sense at all to enable the infrastructure if no
looks at it.
Or in other words: Does the translation team want to have every possible project in Zanata? Or only those they want to translate? And then
question is which ones to translate?
In my mind, translation platform should not block any people who want to translate any resources if the resources are available in Openstack community. So if dev team want to put their resources, put them there.
This is my thinking as well. If the infrastructure is not in place, people are definitely not going to translate it. I understand that people might not translate it anyway, but I don't see the harm in having it available for translation if someone wants that. And as pointed out somewhere else on this topic, python-openstackclient and Horizon both use python-novaclient, so unless those are completely handling all errors that come out of novaclient, we should probably have novaclient available for translations - at least of errors.
Andreas is right, putting projects in Zanata will not bring free translations. Based on my observation, translators prefer to translate UI projects more than other projects. For example, even I include Nova in the Liberty translation plan,
Ying Chun Guo/China/IBM wrote on 2015/09/25 10:17:52: project translator the the
nova translation progress is not that good. In translation community, translation team, coordinators and even individual translators have the autonomy.
So, policy sounds like:
A project that wants translations - and is part of the big tent - can set it up. The i18n PTL suggests a priority and ask for translation of specific projects but translators are not limited on what to translate.
Correct?
Yes.
So, do you want to enable python-keystoneclient, python-novaclient, and
python-neutronclient? Or only the later two since keystoneclient is deprecated and even throws warnings when used:
Pending deprecation: Command-line interface to the OpenStack Identity API. This CLI is pending deprecation in favor of python-openstackclient. For a Python library, continue using python-keystoneclient.
keystoneclient is only used for Python binding and the CLI in is deprecated. So if there is no objections from keystone dev team, we could remove keystoneclient. Please enable openstack-novaclient because we get the request that it needs translation. I don't see neutronclient is deprecating. So please enable it too. Thank you.
Just got inputs from keystone dev team. They said "openstackclient still receives strings from keystoneclient, (it uses keystoneclient to perform the requests) also, keystoneclient can be used by customer applications so they might want translated strings." So let's include python-keystoneclient in the translation projects.
Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126