translating python clients
We now have setup python-keystoneclient for translation and there're requests for python-heatclient and python-novaclient (https://review.openstack.org/224832 heat and https://review.openstack.org/224222 nova) Does it really make sense to translate these? Especially with the openstack client getting translated already? My proposal would be to concentrate on the openstack client and tell the teams to not mark the clients for translation. What do you think? Please see also http://lists.openstack.org/pipermail/openstack-dev/2015-September/073698.htm... 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
Andreas, Forgive me if I ask funny question. I see there is python-openstackclient in Zanata server. What is it for ? What is the relationship between python-openstackclient and other python clients ( e.g python-keystoneclient, python-heatclient, and python-novaclient) ? Best regards Ying Chun Guo (Daisy) Andreas Jaeger <aj@suse.com> wrote on 09/18/2015 01:45:37 AM:
From: Andreas Jaeger <aj@suse.com> To: "openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org> Date: 09/18/2015 01:47 AM Subject: [Openstack-i18n] translating python clients
We now have setup python-keystoneclient for translation and there're requests for python-heatclient and python-novaclient (https://review.openstack.org/224832 heat and https://review.openstack.org/224222 nova)
Does it really make sense to translate these? Especially with the openstack client getting translated already?
My proposal would be to concentrate on the openstack client and tell the
teams to not mark the clients for translation.
What do you think?
Please see also
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073698.htm...
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
On 09/18/2015 10:35 AM, Ying Chun Guo wrote:
Andreas,
Forgive me if I ask funny question.
There are no funny questions, please ask!
I see there is python-openstackclient in Zanata server. What is it for ?
python-openstackclient is the "unnifed OpenStack client" that will replace the per-project clients like python-keystoneclient (command keystone). See http://docs.openstack.org/developer/python-openstackclient/
What is the relationship between python-openstackclient and other python clients ( e.g python-keystoneclient, python-heatclient, and python-novaclient) ?
The goal of python-openstackclient is to replace these. keystoneclient is already deprecated in favor of openstackclient. So, priority wise: openstackclient has higher priority than the others. The question for me is whether we want to translate these already deprecated or in the future deprecated clients at all. Btw. I also think that the python-openstackclient has a higher priority than nova - but lower than horizon. Both horizon and the client address the end user while nova addresses the adminstrator, Andreas
Best regards Ying Chun Guo (Daisy)
Andreas Jaeger <aj@suse.com> wrote on 09/18/2015 01:45:37 AM:
From: Andreas Jaeger <aj@suse.com> To: "openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org> Date: 09/18/2015 01:47 AM Subject: [Openstack-i18n] translating python clients
We now have setup python-keystoneclient for translation and there're requests for python-heatclient and python-novaclient (https://review.openstack.org/224832heat and https://review.openstack.org/224222nova)
Does it really make sense to translate these? Especially with the openstack client getting translated already?
My proposal would be to concentrate on the openstack client and tell the teams to not mark the clients for translation.
What do you think?
Please see also
http://lists.openstack.org/pipermail/openstack-dev/2015-September/073698.htm...
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
-- 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
From: Andreas Jaeger <aj@suse.com> To: Ying Chun Guo/China/IBM@IBMCN Cc: "openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org> Date: 09/18/2015 04:52 PM Subject: Re: [Openstack-i18n] translating python clients
On 09/18/2015 10:35 AM, Ying Chun Guo wrote:
Andreas,
Forgive me if I ask funny question.
There are no funny questions, please ask!
I see there is python-openstackclient in Zanata server. What is it for ?
python-openstackclient is the "unnifed OpenStack client" that will replace the per-project clients like python-keystoneclient (command keystone).
See http://docs.openstack.org/developer/python-openstackclient/
What is the relationship between python-openstackclient and other
clients ( e.g python-keystoneclient, python-heatclient, and python-novaclient) ?
The goal of python-openstackclient is to replace these. keystoneclient is already deprecated in favor of openstackclient.
So, priority wise: openstackclient has higher priority than the others. The question for me is whether we want to translate these already deprecated or in the future deprecated clients at all.
Btw. I also think that the python-openstackclient has a higher priority than nova - but lower than horizon. Both horizon and the client address the end user while nova addresses the adminstrator,
Andreas
Best regards Ying Chun Guo (Daisy)
Andreas Jaeger <aj@suse.com> wrote on 09/18/2015 01:45:37 AM:
From: Andreas Jaeger <aj@suse.com> To: "openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org> Date: 09/18/2015 01:47 AM Subject: [Openstack-i18n] translating python clients
We now have setup python-keystoneclient for translation and
very important information. I don't think translators would like to translate already deprecated or in the future deprecated clients. I might not be able to include openstack client in the Liberty translation plan. But I would put it high priority after Liberty translation. And next release, I will add openstack client to in the translation plan. Best regards Ying Chun Guo (Daisy) Andreas Jaeger <aj@suse.com> wrote on 09/18/2015 04:51:32 PM: python there're
requests for python-heatclient and python-novaclient (https://review.openstack.org/224832heat and https://review.openstack.org/224222nova)
Does it really make sense to translate these? Especially with the openstack client getting translated already?
My proposal would be to concentrate on the openstack client and tell the teams to not mark the clients for translation.
What do you think?
Please see also
http://lists.openstack.org/pipermail/openstack-dev/2015-September/ 073698.html
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 563CC272 A126
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- 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
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. For other topics, I will comment on them later if necessary. Akihiro 2015-09-18 22:33 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com>:
very important information. I don't think translators would like to translate already deprecated or in the future deprecated clients. I might not be able to include openstack client in the Liberty translation plan. But I would put it high priority after Liberty translation. And next release, I will add openstack client to in the translation plan.
Best regards Ying Chun Guo (Daisy)
Andreas Jaeger <aj@suse.com> wrote on 09/18/2015 04:51:32 PM:
From: Andreas Jaeger <aj@suse.com> To: Ying Chun Guo/China/IBM@IBMCN Cc: "openstack-i18n@lists.openstack.org" < openstack-i18n@lists.openstack.org> Date: 09/18/2015 04:52 PM Subject: Re: [Openstack-i18n] translating python clients
On 09/18/2015 10:35 AM, Ying Chun Guo wrote:
Andreas,
Forgive me if I ask funny question.
There are no funny questions, please ask!
I see there is python-openstackclient in Zanata server. What is it for ?
python-openstackclient is the "unnifed OpenStack client" that will replace the per-project clients like python-keystoneclient (command keystone).
See http://docs.openstack.org/developer/python-openstackclient/
What is the relationship between python-openstackclient and other python clients ( e.g python-keystoneclient, python-heatclient, and python-novaclient) ?
The goal of python-openstackclient is to replace these. keystoneclient is already deprecated in favor of openstackclient.
So, priority wise: openstackclient has higher priority than the others. The question for me is whether we want to translate these already deprecated or in the future deprecated clients at all.
Btw. I also think that the python-openstackclient has a higher priority than nova - but lower than horizon. Both horizon and the client address the end user while nova addresses the adminstrator,
Andreas
Best regards Ying Chun Guo (Daisy)
Andreas Jaeger <aj@suse.com> wrote on 09/18/2015 01:45:37 AM:
From: Andreas Jaeger <aj@suse.com> To: "openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org> Date: 09/18/2015 01:47 AM Subject: [Openstack-i18n] translating python clients
We now have setup python-keystoneclient for translation and there're requests for python-heatclient and python-novaclient (https://review.openstack.org/224832heat and https://review.openstack.org/224222nova)
Does it really make sense to translate these? Especially with the openstack client getting translated already?
My proposal would be to concentrate on the openstack client and tell the teams to not mark the clients for translation.
What do you think?
Please see also
http://lists.openstack.org/pipermail/openstack-dev/2015-September/
073698.html
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 563CC272 A126
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- 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
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.
For other topics, I will comment on them later if necessary.
Akihiro
2015-09-18 22:33 GMT+09:00 Ying Chun Guo <guoyingc@cn.ibm.com <mailto:guoyingc@cn.ibm.com>>:
very important information. I don't think translators would like to translate already deprecated or in the future deprecated clients. I might not be able to include openstack client in the Liberty translation plan. But I would put it high priority after Liberty translation. And next release, I will add openstack client to in the translation plan.
Best regards Ying Chun Guo (Daisy)
Andreas Jaeger <aj@suse.com <mailto:aj@suse.com>> wrote on 09/18/2015 04:51:32 PM:
> From: Andreas Jaeger <aj@suse.com <mailto:aj@suse.com>> > To: Ying Chun Guo/China/IBM@IBMCN > Cc: "openstack-i18n@lists.openstack.org <mailto:openstack-i18n@lists.openstack.org>" <openstack-i18n@lists.openstack.org <mailto:openstack-i18n@lists.openstack.org>> > Date: 09/18/2015 04:52 PM > Subject: Re: [Openstack-i18n] translating python clients > > On 09/18/2015 10:35 AM, Ying Chun Guo wrote: > > Andreas, > > > > Forgive me if I ask funny question. > > There are no funny questions, please ask! > > > I see there is python-openstackclient in Zanata server. > > What is it for ? > > python-openstackclient is the "unnifed OpenStack client" that will > replace the per-project clients like python-keystoneclient (command > keystone). > > See http://docs.openstack.org/developer/python-openstackclient/ > > > What is the relationship between python-openstackclient and other python > > clients ( e.g python-keystoneclient, > > python-heatclient, and python-novaclient) ? > > The goal of python-openstackclient is to replace these. keystoneclient > is already deprecated in favor of openstackclient. > > So, priority wise: openstackclient has higher priority than the others. > The question for me is whether we want to translate these already > deprecated or in the future deprecated clients at all. > > Btw. I also think that the python-openstackclient has a higher priority > than nova - but lower than horizon. Both horizon and the client address > the end user while nova addresses the adminstrator, > > Andreas > > > Best regards > > Ying Chun Guo (Daisy) > > > > > > Andreas Jaeger <aj@suse.com <mailto:aj@suse.com>> wrote on 09/18/2015 01:45:37 AM: > > > > > From: Andreas Jaeger <aj@suse.com <mailto:aj@suse.com>> > > > To: "openstack-i18n@lists.openstack.org <mailto:openstack-i18n@lists.openstack.org>" > > <openstack-i18n@lists.openstack.org <mailto:openstack-i18n@lists.openstack.org>> > > > Date: 09/18/2015 01:47 AM > > > Subject: [Openstack-i18n] translating python clients > > > > > > We now have setup python-keystoneclient for translation and there're > > > requests for python-heatclient and python-novaclient > > > (https://review.openstack.org/224832heatand > > > https://review.openstack.org/224222nova) > > > > > > Does it really make sense to translate these? Especially with the > > > openstack client getting translated already? > > > > > > My proposal would be to concentrate on the openstack client and tell the > > > teams to not mark the clients for translation. > > > > > > What do you think? > > > > > > Please see also > > > > > http://lists.openstack.org/pipermail/openstack-dev/2015-September/
> 073698.html > > > > > > Andreas > > > -- > > > Andreas Jaeger aj@{suse.com <http://suse.com>,opensuse.org <http://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 563CC272 A126 > > > > > > > > > _______________________________________________ > > > Openstack-i18n mailing list > > >Openstack-i18n@lists.openstack.org <mailto:Openstack-i18n@lists.openstack.org> > > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
> > > -- > Andreas Jaeger aj@{suse.com <http://suse.com>,opensuse.org <http://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 <mailto:Openstack-i18n@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
_______________________________________________ Openstack-i18n mailing list Openstack-i18n@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Thanks, Matt Riedemann
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? 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
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
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
Andreas Jaeger <aj@suse.com> wrote on 09/21/2015 10:27:29 PM: translations. 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
On 9/21/2015 10:49 AM, Ying Chun Guo wrote:
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
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
have microversion support in it for the compute API, which I don't
translations. that we 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n
-- Thanks, Matt Riedemann
On 2015-09-22 22:53, Matt Riedemann wrote:
On 9/21/2015 10:49 AM, Ying Chun Guo wrote:
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
* 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
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
have microversion support in it for the compute API, which I don't
here. translations. that we 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
Daisy, can you confirm and suggest what to do with the clients, please? Andreas
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
From: Andreas Jaeger <aj@suse.com> To: Matt Riedemann <mriedem@linux.vnet.ibm.com>, Ying Chun Guo/China/IBM@IBMCN Cc: openstack-i18n@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@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
more deeply to decide translation priorties before starting
cycle 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
Andreas Jaeger <aj@suse.com> wrote on 2015/09/23 15:06:56: 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
participants (4)
-
Akihiro Motoki
-
Andreas Jaeger
-
Matt Riedemann
-
Ying Chun Guo