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
