<html><body>
<p><tt><font size="2">Ying Chun Guo/China/IBM wrote on 2015/09/25 10:17:52:<br>
<br>
> From: Ying Chun Guo/China/IBM</font></tt><br>
<tt><font size="2">> To: Andreas Jaeger <aj@suse.com></font></tt><br>
<tt><font size="2">> Cc: Matt Riedemann <mriedem@linux.vnet.ibm.com>, openstack-<br>
> i18n@lists.openstack.org</font></tt><br>
<tt><font size="2">> Date: 2015/09/25 10:17</font></tt><br>
<tt><font size="2">> Subject: Re: [Openstack-i18n] translating python clients</font></tt><br>
<tt><font size="2">> <br>
> 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/<br>
> 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>
<tt><font size="2">> <br>
> 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>
<tt><font size="2">> <br>
> 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<br>
> keystoneclient.</font></tt><br>
<tt><font size="2">> Please enable openstack-novaclient because we get the request that <br>
> 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">></font></tt><br>
<br>
<tt><font size="2">Just got inputs from keystone dev team.</font></tt><br>
<tt><font size="2">They said </font></tt><br>
<tt><font size="2">"openstackclient still receives strings from keystoneclient, </font></tt><br>
<tt><font size="2">(it uses keystoneclient to perform the requests)</font></tt><br>
<tt><font size="2">also, keystoneclient can be used by customer applications </font></tt><br>
<tt><font size="2">so they might want translated strings."</font></tt><br>
<tt><font size="2">So let's include python-keystoneclient in the translation projects.</font></tt><br>
<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>