Andreas Jaeger <aj@suse.com> wrote on 09/21/2015
10:27:29 PM:
> From: Andreas Jaeger <aj@suse.com>
> To: Matt Riedemann <mriedem@linux.vnet.ibm.com>,
openstack-
> i18n@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@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
>