Open Stack

On 10/10/2014 06:28 PM, Akihiro Motoki wrote:
> Andreas and Elizabeth,
> 
> Nice write-up.
> 
> I have one question about the below description in the process
> (without reading the infra code, sorry).
> 
>> 2. The script connects to transifex and asks to download for each resource all "sufficiently translated" files. We define "sufficiently" as at least 75 per cent of strings are translated.
> 
> Once 75% of strings are translated, the corresponding resource is downloaded.
> Will the resource be updated later even if the percentage of
> translated strings becomes <75%?
> IMHO it is better to be updated even if the percentage is <75% when
> the resource exists in $PROJECT repo.
> It can be done by "tx pull" without "-a" option.

Right now the script does not download anything if it less than 75 %.
If the 75 % number does not work, we can change it - and patches to
implement your idea are welcome as well ;)

> (Of course the percentage becomes <20%, the resource will be removed.)
> 
>> 9. If there are troubles with the patch, a core should send a message to the i18n team (AJaeger is on their mailing list) and tell about the problem. Then somebody needs to investigate whether translations or tools are broken.
> 
> I can volunteer for trouble shooting too.

Thanks, please add yourself to the wiki - that's why I suggested the
mailing list.

> 
> Beyond this document, I think we need to document how to manage
> translations during RC phase (after RC1 is cut).

Yes.

> (to transifex)
> We need to update Transifex resources manually once RC1 is cut.
> Luckily enough, after RC1 the barrier of new patches becomes very high
> and we rarely see new strings, so it doesn't matter. Considering it,
> IMHO we don't need to support Transifex resource update during this
> special period.
> 
> (from transifex to git repo)
> Translation importing is still a manual process. Personally it also
> can be a manual process to some extent.
> We need to propose a patch to "proposed/xxxx" branch directly, so it
> is still better to be done manually.
> We only need one volunteer for a release.
> 
> In Horizon case, I18N team has a consensus to ship almost 100%
> translations are shipped (the threshold is usually 90~95%), so we need
> an extra step.
> (My script [1] assists me to propose a patch. I usually just need to
> run "propose-trans.sh",
> "git commit", "run_test.sh" and then "git review".)
> 
> I saw you advices how to update message catalogs in several projects.
> Looking at this, more automated process (or better scripts) are needed.
> 
> These are future possible improvements.
> 
> 
> Transifex does not support a branch mechanism, so we need to rename resources
> and create new resources (or to create resources for stable). It is
> really a headache for us.

could you add this to the wiki page, please?

This is really important for evaluation of transifex alternatives,

thanks!
Andreas

> Thanks,
> Akihiro
> 
> [1] https://github.com/amotoki/horizon-i18n-tools
> 
> On Fri, Oct 10, 2014 at 3:33 AM, Andreas Jaeger <aj at suse.com> wrote:
>> Elizabeth and myself just had a documentation session and created the
>> following wiki page to document what our infra scripts do:
>>
>> https://wiki.openstack.org/wiki/Translations/Infrastructure
>>
>> If you have any questions, please ask - and let's improve the
>> documentation further!
>>
>> 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 at 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