Open Stack

On 03/31/2014 04:18 PM, Akihiro Motoki wrote:
> On Sat, Mar 22, 2014 at 4:46 AM, Andreas Jaeger <aj at 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).
> 

Importing is only done to *master*, never to any other branches, so this
should be fine,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: 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