Open Stack

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.

> 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/35b16aab/attachment-0001.html>