Re: [openstack-dev] [tripleo][ui] Now with translations :)

2017-02-07 Thread Julie Pichon 
On 6 February 2017 at 16:03, Ben Nemec  wrote:
> On 02/06/2017 05:38 AM, Julie Pichon wrote:
>>
>> Hi folks,
>>
>> You may have noticed a new type of patch in our queue this morning
>> [1]. There's a nice link in the commit message [2][3] that describes
>> what to do with it (TL;DR: check the structure is correct, merge it
>> quickly - most projects have a single core approval policy for these
>> as well, which I wasn't aware of. Nice!).
>
> Can you propose adding this to the expedited approvals policy?
> https://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html

Done! https://review.openstack.org/#/c/430195/

TripleO UI cores, I also added you as reviewers since you are
currently the main people affected.

Thanks,

Julie

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo][ui] Now with translations :)

2017-02-06 Thread Ben Nemec 



On 02/06/2017 05:38 AM, Julie Pichon wrote:

Hi folks,

You may have noticed a new type of patch in our queue this morning
[1]. There's a nice link in the commit message [2][3] that describes
what to do with it (TL;DR: check the structure is correct, merge it
quickly - most projects have a single core approval policy for these
as well, which I wasn't aware of. Nice!).


Can you propose adding this to the expedited approvals policy? 
https://specs.openstack.org/openstack/tripleo-specs/specs/policy/expedited-approvals.html


Thanks.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo][ui] Now with translations :)

2017-02-06 Thread Julie Pichon 
Hi folks,

You may have noticed a new type of patch in our queue this morning
[1]. There's a nice link in the commit message [2][3] that describes
what to do with it (TL;DR: check the structure is correct, merge it
quickly - most projects have a single core approval policy for these
as well, which I wasn't aware of. Nice!).

While enabling this I received a couple a questions around the infra
workflows so I thought I'd give the team a quick overview of how our
repo is integrated with Zanata and what it means for the project.

How it works
--

1. Translations happen on Zanata at [4]. Never modify a translation in
a json file directly. You can join the i18n team for your language(s)
at [5] if you'd like to help translating!

2. Whenever a patch that contains new internationalised strings
merges, the strings on Zanata are updated.

3. Once a day a script checks for new translations, and proposes an
automated patch like [1] to our repo (if most of the strings for that
language are translated).

Things to be careful about from now on
---

1. Please don't hardcode strings anymore, always make them
internationalisable and keep an eye out for this during reviews. You
can look at one of the existing i18n patches to figure out how to do
it, and maybe we can update our docs with a how-to/point to the i18n
library docs.

2. We need to be careful about modifying strings, especially in
backports in the future as that invalidates translations.

3. We need to be careful about Soft String Freeze (don't modify
strings anymore, additions are ok) and Hard String Freeze (don't
accept patches with any of kind of string changes) in the schedule [6]
from now on, to give translators time to work. (We may have 1-2 weeks
of "cycle-trailing" wiggle room for each deadline.)

4. If you are a core reviewer, please try to review and get
translation patches merged as soon as possible, particularly after the
Freezes. It gives translators a chance to check and review the
translations on a test system before the release.

5. I proposed a new 'i18n' bug tag [7] for tracking i18n issues (most
likely, missing strings that were hardcoded). It'd be cool if we could
try to prioritise fixing these when they come up between Soft String
Freeze and RC, whenever it's possible/reasonable to do so. So that
translators may have a chance to update the translation for the
corrected string before the release.


The OpenStack i18n team is small and overloaded, so I don't think the
community will be able to prioritise translating the UI in general,
however we do have a couple of individual translators who will be
working on Ocata translations for us. Let's try to make their job as
easy as possible :)

Thank you!

Julie

[1] https://review.openstack.org/#/c/429203/
[2] http://docs.openstack.org/project-team-guide/i18n.html
[3] http://docs.openstack.org/developer/i18n/reviewing-translation-import.html
[4] https://translate.openstack.org/project/view/tripleo-ui
[5] http://docs.openstack.org/developer/i18n/contributing.html
[6] https://releases.openstack.org/ocata/schedule.html
[7] https://review.openstack.org/#/c/429613/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev