[Openstack-i18n] translating python clients

Matt Riedemann mriedem at linux.vnet.ibm.com
Tue Sep 22 20:53:11 UTC 2015



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

-- 

Thanks,

Matt Riedemann




More information about the Openstack-i18n mailing list