Open Stack

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.
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.

> 
> 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
> 
> 
> _______________________________________________
> Openstack-i18n mailing list
> Openstack-i18n at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20150921/a899b5be/attachment-0001.html>