Open Stack

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?

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.

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