Hi Daisy, upstream_translation_update.sh and propose_translation_update.sh are general and IMO if we have special cases it is better to deal with it by a separate script, in this case horizon_*.sh. What do you think? Besides that, django_openstack_auth is a bit special case for translations. Strings in django_openstack_auth are visible through Horizon and from UX perspective and most translation efforts are done as a part of Dashboard translations, so it sounds reasonable it is placed under Horizon project. I would like to raise the following points to be discussed related to django_openstack_auth translations. - django_openstack_auth is a separate library and it is not controlled under OpenStack release cycle. Thus transifex resources with "havana" or OpenStack release code names looks inappropriate. Transifex resource management should match corresponding project release cycle. At least "Havana - OpenStack Dashboard Authentication" on Transifex does not looks reasonable to me. I see some translation updates in "Havana - OpenStack Dashboard Authentication " and changes are translation fixies. I just want to talk about how to handle them: when should I propose a change to the upstream? - Translation import timing: I am not sure automatic translation import is good or not. Now I18N and Horizon team do not use automatic import to control translation quality. In Havana cycle, django_openstack_auth translation is controlled with the same policy but if propose_translation_update.sh works translations are imported automatically. Is it intended? Note that there are very few string changes in django_openstack_auth so this doesn't matter much. Thanks, Akihiro On Fri, Mar 21, 2014 at 6:19 PM, Andreas Jaeger <aj@suse.com> wrote:

On 03/21/2014 09:18 AM, Ying Chun Guo wrote:

...

Hello, Andreas

django_openstack_auth uses the script "upstream_translation_update.sh" and accept "django_openstack_auth" as a parameter. The script "upstream_translation_update.sh" is a common job definition and works for nova, glance, and etc. As to current situation, I wonder if it can accept "openstack_auth" as the parameter.

Yes, it needs a resource in Transifex. I have created: https://www.transifex.com/projects/p/horizon/resource/djangopo/

We need to special case this setup so that it ends at the right place, what do you think of this patch: https://review.openstack.org/82037

Please check that all filenames - also in the repository and transifex match, this is tricky.

Andreas

...

But I use the po file as the source, not the pot.

Best regards Ying Chun Guo (Daisy)

Andreas Jaeger <aj@suse.com> wrote on 2014/03/21 03:24:37:

...

Andreas Jaeger <aj@suse.com> 2014/03/21 03:24

To

"openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org>,

cc

Subject

[Openstack-i18n] django_openstack_auth translation setup?

Hi translation team, I'm trying to fix some more translation jobs and run into a issue with the django_openstack_auth setup.

django_openstack_auth setup looks broken, the job fails to run since it expects: django_openstack_auth/locale/django_openstack_auth.pot

but the repository uses: openstack_auth/locale/openstack_auth.pot

I can fix this but need a bit of guidance here.

Where this should get added for translation - will this be a resource in the horizon project in transifex - as it was in havana?

And is the name django.po for the LC_MESSAGES file really correct in the repo?

Btw. Jenkins output: https://jenkins.openstack.org/job/django_openstack_auth-upstream- translation-update/lastBuild/console

Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (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 Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (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 Sat, Mar 22, 2014 at 4:46 AM, Andreas Jaeger <aj@suse.com> wrote:

On 03/21/2014 07:45 PM, Akihiro Motoki wrote:

...

Hi Daisy,

upstream_translation_update.sh and propose_translation_update.sh are general and IMO if we have special cases it is better to deal with it by a separate script, in this case horizon_*.sh. What do you think?

Yeah, I was wondering that as well. The files share a lot but the special casing makes the script more complex.

...

Besides that, django_openstack_auth is a bit special case for translations. Strings in django_openstack_auth are visible through Horizon and from UX perspective and most translation efforts are done as a part of Dashboard translations, so it sounds reasonable it is placed under Horizon project.

I would like to raise the following points to be discussed related to django_openstack_auth translations.

- django_openstack_auth is a separate library and it is not controlled under OpenStack release cycle. Thus transifex resources with "havana" or OpenStack release code names looks inappropriate. Transifex resource management should match corresponding project release cycle. At least "Havana - OpenStack Dashboard Authentication" on Transifex does not looks reasonable to me.

That one exists already for some time AFAIU.

...

I see some translation updates in "Havana - OpenStack Dashboard Authentication " and changes are translation fixies. I just want to talk about how to handle them: when should I propose a change to the upstream?

- Translation import timing: I am not sure automatic translation import is good or not. Now I18N and Horizon team do not use automatic import to control translation quality. In Havana cycle, django_openstack_auth translation is controlled with the same policy but if propose_translation_update.sh works translations are imported automatically. Is it intended?

is this documented anywhere? I just started working on this without reading, guess it's time to do so now.

Right now we have jobs setup that run these jobs - and fail. So, somebody considered it a good idea...

I forgot to reply. There is no documentation on it. On a second thought, automatic translation importing to *master* branch looks good. It applies to master branch, so we can still make additional changes after RC1 is shipped if needed (by patching directly to milestone-proposed branch). Thanks, Akihiro

Andreas

...

Note that there are very few string changes in django_openstack_auth so this doesn't matter much.

Thanks, Akihiro

On Fri, Mar 21, 2014 at 6:19 PM, Andreas Jaeger <aj@suse.com> wrote:

...

On 03/21/2014 09:18 AM, Ying Chun Guo wrote:

...

Hello, Andreas

django_openstack_auth uses the script "upstream_translation_update.sh" and accept "django_openstack_auth" as a parameter. The script "upstream_translation_update.sh" is a common job definition and works for nova, glance, and etc. As to current situation, I wonder if it can accept "openstack_auth" as the parameter.

Yes, it needs a resource in Transifex. I have created: https://www.transifex.com/projects/p/horizon/resource/djangopo/

We need to special case this setup so that it ends at the right place, what do you think of this patch: https://review.openstack.org/82037

Please check that all filenames - also in the repository and transifex match, this is tricky.

Andreas

...

But I use the po file as the source, not the pot.

Best regards Ying Chun Guo (Daisy)

Andreas Jaeger <aj@suse.com> wrote on 2014/03/21 03:24:37:

...

Andreas Jaeger <aj@suse.com> 2014/03/21 03:24

To

"openstack-i18n@lists.openstack.org" <openstack-i18n@lists.openstack.org>,

cc

Subject

[Openstack-i18n] django_openstack_auth translation setup?

Hi translation team, I'm trying to fix some more translation jobs and run into a issue with the django_openstack_auth setup.

django_openstack_auth setup looks broken, the job fails to run since it expects: django_openstack_auth/locale/django_openstack_auth.pot

but the repository uses: openstack_auth/locale/openstack_auth.pot

I can fix this but need a bit of guidance here.

Where this should get added for translation - will this be a resource in the horizon project in transifex - as it was in havana?

And is the name django.po for the LC_MESSAGES file really correct in the repo?

Btw. Jenkins output: https://jenkins.openstack.org/job/django_openstack_auth-upstream- translation-update/lastBuild/console

Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (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 Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (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 Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Sorry for coming back quite late to this. On 03/21/2014 07:45 PM, Akihiro Motoki wrote:

Hi Daisy,

upstream_translation_update.sh and propose_translation_update.sh are general and IMO if we have special cases it is better to deal with it by a separate script, in this case horizon_*.sh. What do you think?

We can either create a completely new script for it - or reuse the general ones. The horizon scripts are so special case that reusing them for django_openstack_auth does not make sense at all. I'll remove the WIP now and let's see what the infra team says on the patch and I'll rework it from there - additional review from all of you is welcomes as well ;) https://review.openstack.org/#/c/82037

Besides that, django_openstack_auth is a bit special case for translations. Strings in django_openstack_auth are visible through Horizon and from UX perspective and most translation efforts are done as a part of Dashboard translations, so it sounds reasonable it is placed under Horizon project.

I would like to raise the following points to be discussed related to django_openstack_auth translations.

- django_openstack_auth is a separate library and it is not controlled under OpenStack release cycle. Thus transifex resources with "havana" or OpenStack release code names looks inappropriate. Transifex resource management should match corresponding project release cycle. At least "Havana - OpenStack Dashboard Authentication" on Transifex does not looks reasonable to me.

I see some translation updates in "Havana - OpenStack Dashboard Authentication " and changes are translation fixies. I just want to talk about how to handle them: when should I propose a change to the upstream?

- Translation import timing: I am not sure automatic translation import is good or not. Now I18N and Horizon team do not use automatic import to control translation quality. In Havana cycle, django_openstack_auth translation is controlled with the same policy but if propose_translation_update.sh works translations are imported automatically. Is it intended?

Note that there are very few string changes in django_openstack_auth so this doesn't matter much.

I suggest to give it a try - shall we? Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

I am not sure which is better to move django_openstack_auth to a separate project in Transifex or to keep it as a part of Horizon project in Transifex. In general it looks reasonable to move django_openstack_auth to a separate project. Only thing I concern is that strings from django_openstack_auth is also visible as a part of OpenStack dashboard and splitting django_openstack_auth makes it difficult to identify a string when translator finds a wrong string. I would like to know input from others from the point of view of (pure) translators. I already know too much detail of translations/horizon/openstack infra mechanism and I am afraid I cannot make an appropriate decision from translator perspective. Thanks, Akihiro On Mon, Apr 28, 2014 at 2:51 AM, Andreas Jaeger <aj@suse.com> wrote:

On 03/21/2014 10:19 AM, Andreas Jaeger wrote:

...

On 03/21/2014 09:18 AM, Ying Chun Guo wrote:

...

Hello, Andreas

django_openstack_auth uses the script "upstream_translation_update.sh" and accept "django_openstack_auth" as a parameter. The script "upstream_translation_update.sh" is a common job definition and works for nova, glance, and etc. As to current situation, I wonder if it can accept "openstack_auth" as the parameter.

Yes, it needs a resource in Transifex. I have created: https://www.transifex.com/projects/p/horizon/resource/djangopo/

We need to special case this setup so that it ends at the right place, what do you think of this patch: https://review.openstack.org/82037

Please check that all filenames - also in the repository and transifex match, this is tricky.

thinking further, it would be much easier, if the transifex setup would not be part of horizon but a separate repository following the naming scheme we use elsewhere - so set this up under https://www.transifex.com/projects/p/django_openstack_auth/resource/openstac.... Could you adjust this, please?

Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (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