Open Stack

Ying Chun Guo/China/IBM wrote on 2015/09/25 10:17:52:

> From: Ying Chun Guo/China/IBM
> To: Andreas Jaeger <aj at suse.com>
> Cc: Matt Riedemann <mriedem at linux.vnet.ibm.com>, openstack-
> i18n at lists.openstack.org
> Date: 2015/09/25 10:17
> Subject: Re: [Openstack-i18n] translating python clients
>
> Andreas Jaeger <aj at suse.com> wrote on 2015/09/23 15:06:56:
>
> > From: Andreas Jaeger <aj at suse.com>
> > To: Matt Riedemann <mriedem at linux.vnet.ibm.com>, Ying Chun Guo/
> China/IBM at IBMCN
> > Cc: openstack-i18n at 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 at suse.com> wrote on 09/21/2015 10:27:29 PM:
> > >>
> > >>  > From: Andreas Jaeger <aj at suse.com>
> > >>  > To: Matt Riedemann <mriedem at linux.vnet.ibm.com>, openstack-
> > >>  > i18n at 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
project
> > >> wasn't
> > >>  > > 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
> > >> that we
> > >>  > > have microversion support in it for the compute API, which I
don't
> > >> 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
translator
> > >>  > 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
the
> > >>  > 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,
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
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20150925/9e965434/attachment-0001.html>