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