- OpenStack-I18n - lists.openstack.org

[Bug 1587221] [NEW] openstack-manuals stable-mitaka releasenotes on Zanata looks unnecessary
by Akihiro Motoki 20 Sep '16

20 Sep '16

Public bug reported: As we discussed at Austin, only the master version is required for release notes translation on Zanata. Zanata currently has openstack- manuals stable-mitaka releasenotes resource. It looks unnecessary. ** Affects: openstack-i18n Importance: Undecided Status: New ** Tags: infra -- You received this bug notification because you are a member of OpenStack I18n Core Team, which is subscribed to openstack i18n. https://bugs.launchpad.net/bugs/1587221 Title: openstack-manuals stable-mitaka releasenotes on Zanata looks unnecessary Status in openstack i18n: New Bug description: As we discussed at Austin, only the master version is required for release notes translation on Zanata. Zanata currently has openstack- manuals stable-mitaka releasenotes resource. It looks unnecessary. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-i18n/+bug/1587221/+subscriptions

2 1

[Bug 1571100] Re: 技术因素 in OpenStack 架构设计指南 - 当前最新
by Ian Y. Choi 20 Sep '16

20 Sep '16

Hmm.. I cannot check "Won't fix". Instead, I will triage as "Opinion". ** Changed in: openstack-i18n Status: Confirmed => Opinion -- You received this bug notification because you are a member of OpenStack I18n Core Team, which is subscribed to openstack i18n. https://bugs.launchpad.net/bugs/1571100 Title: 技术因素 in OpenStack 架构设计指南 - 当前最新 Status in openstack i18n: Opinion Bug description: Error "Redia"是一个key-value存储系统 Redis是一个key-value存储系统 ----------------------------------- Built: 2015-11-24T07:19:53 00:00 git SHA: ed0b07948cdc10b7fb962ec8aba3c3cb299fe053 URL: http://docs.openstack.org/zh_CN/arch-design/content/technical-consideration… source File: file:/home/jenkins/workspace/openstack-manuals-tox-doc-publishlang/generated/zh_CN/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml xml:id: technical-considerations-general-purpose To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-i18n/+bug/1571100/+subscriptions

1 0

[Bug 1535172] Re: Wrong typesetting in Chinese OpenStack Mitaka and master install doc
by Ian Y. Choi 20 Sep '16

20 Sep '16

Thanks a lot for your comment, Shengjing! ** Summary changed: - Wrong typesetting in Chinese OpenStack Liberty install doc + Wrong typesetting in Chinese OpenStack Mitaka and master install doc ** Changed in: openstack-i18n Status: Confirmed => Fix Released -- You received this bug notification because you are a member of OpenStack I18n Core Team, which is subscribed to openstack i18n. https://bugs.launchpad.net/bugs/1535172 Title: Wrong typesetting in Chinese OpenStack Mitaka and master install doc Status in openstack i18n: Fix Released Bug description: Extra underline in the doc. The translated link is http://docs.openstack.org/liberty/zh_CN/install-guide-rdo/glance-install.ht… The original doc link is http://docs.openstack.org/liberty/install-guide-rdo/glance-install.html The picture is attached. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-i18n/+bug/1535172/+subscriptions

1 0

[Bug 1608992] [NEW] [api-quick-start] Some old translated pages are still being seen
by Ian Y. Choi 20 Sep '16

20 Sep '16

Public bug reported: Previously, API quick start documentation was xml-based format (with maven build). Since all the API quick start content is written as RST format now, docs.openstack.org/api/quick-start/ url is redirected to current API quick start URL like http://developer.openstack.org/api-guide/quick-start/index.html . I have found some of current problems which can be interpreted as bugs: - Not all translated RST documentation is visible : Although current translation is ~100% in Chinese (zh_CN), http://docs.openstack.org/zh_CN/api/quick-start/content/index.html (xml based) is okay, but http://developer.openstack.org/zh_CN/api-guide/quick-start/ url is not working. - No redirection to rst based documentation : For example, when users enter the previous Japanese API quick-start using docs.openstack.org/ja/api/quick-start/ , the old page is still being seen. On the other hand, English docs.openstack.org/api/quick-start url is redirected to current API quick start URL like http://developer.openstack.org/api-guide/quick-start/index.html . - Even though translation progress seems to be good, there is no rst- based generated documentation for zh_CN (Chinese) and id (Indonesia) So, currently, my approach to address this bug is: 1) Identify which languages have good progress on api-quick-start translation 2) Include that those languages need to build 3) After checking the documentation result on public web pages, we need to add url redirection. ** Affects: openstack-api-site Importance: Undecided Assignee: Ian Y. Choi (ianychoi) Status: In Progress ** Affects: openstack-i18n Importance: Undecided Assignee: Ian Y. Choi (ianychoi) Status: New ** Also affects: openstack-api-site Importance: Undecided Status: New ** Changed in: openstack-api-site Assignee: (unassigned) => Ian Y. Choi (ianychoi) ** Changed in: openstack-i18n Assignee: (unassigned) => Ian Y. Choi (ianychoi) -- You received this bug notification because you are a member of OpenStack I18n Core Team, which is subscribed to openstack i18n. https://bugs.launchpad.net/bugs/1608992 Title: [api-quick-start] Some old translated pages are still being seen Status in openstack-api-site: In Progress Status in openstack i18n: New Bug description: Previously, API quick start documentation was xml-based format (with maven build). Since all the API quick start content is written as RST format now, docs.openstack.org/api/quick-start/ url is redirected to current API quick start URL like http://developer.openstack.org/api-guide/quick-start/index.html . I have found some of current problems which can be interpreted as bugs: - Not all translated RST documentation is visible : Although current translation is ~100% in Chinese (zh_CN), http://docs.openstack.org/zh_CN/api/quick-start/content/index.html (xml based) is okay, but http://developer.openstack.org/zh_CN/api-guide/quick-start/ url is not working. - No redirection to rst based documentation : For example, when users enter the previous Japanese API quick-start using docs.openstack.org/ja/api/quick-start/ , the old page is still being seen. On the other hand, English docs.openstack.org/api/quick-start url is redirected to current API quick start URL like http://developer.openstack.org/api-guide/quick-start/index.html . - Even though translation progress seems to be good, there is no rst- based generated documentation for zh_CN (Chinese) and id (Indonesia) So, currently, my approach to address this bug is: 1) Identify which languages have good progress on api-quick-start translation 2) Include that those languages need to build 3) After checking the documentation result on public web pages, we need to add url redirection. To manage notifications about this bug go to: https://bugs.launchpad.net/openstack-api-site/+bug/1608992/+subscriptions

1 3

What happens in openstack-manual on Zanata?
by Akihiro Motoki 20 Sep '16

20 Sep '16

Hi, I see many many 'common' in openstack-manual project on Zanata? https://translate.openstack.org/iteration/view/openstack-manuals/master/doc… 'common' in openstack-manuals are linked into individual guides and they are uploaded by accident. Is there any change around upstream_translation_update.sh ? Akihiro

4 3

First stable/newton branches created
by Andreas Jaeger 19 Sep '16

19 Sep '16

Could somebody please set up stable-newton branches for those projects that should get translations of them, please? With RC1 today, projects are creating stable/newton branches now, Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

4 14

[horizon] Question on a singular/plural string use in openstack_dashboard
by Ian Y. Choi 19 Sep '16

19 Sep '16

Hello, Recently, thanks to the help from Andreas, I am investigating on a broken job for the translation import of Horizon project [1]. The actual error message is : openstack_dashboard/locale/ko_KR/LC_MESSAGES/django.po:8273: a format specification for argument 'req' doesn't exist in 'msgstr[0]' And then I have found that this error was from a string in horizon - openstack_dashboard [2] error_message = ungettext_lazy( 'The requested instance cannot be launched as you only ' 'have %(avail)i of your quota available. ', 'The requested %(req)i instances cannot be launched as you ' 'only have %(avail)i of your quota available.', count) params = {'req': count, 'avail': available_count} In i18n translation infrastructure, only one of two (for singular and plural) strings should be selected, translated, saved, and finally imported back to Horizon project as [1]. However, the first string only used "%(avail)i" string variable, and the second string used both "%(req)i" and "%(avail)i" string variables. Since one Korean translator selected the first string, there will be no "%(req)i" in Korean po file, which generates such an error. So my suggestion is to use the same string variables for both two strings when we use ungettext_lazy function. Is it a bug from Horizon? Would it be other issues when we change like : from 'The requested instance cannot be launched as you only ' to 'The requested %(req)i instance cannot be launched as you only '? [1] http://logs.openstack.org/periodic/horizon-propose-translation-update/c038a… [2] http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/da… With many thanks, /Ian

4 8

Re: [OpenStack-I18n] [openstack-dev] [stable] [all] Regarding string freeze and back ports involving translatable strings
by Ian Y. Choi 18 Sep '16

18 Sep '16

Hello, First of all, a little bit sorry for following this thread late. I am a Korean translator. Translation is also one of important and vital parts within OpenStack "Big Tent". Although the hard string freeze period before final release date is only for 3 weeks, many I18n language teams focus on translations during that period intensively. For example, Horizon translation results on lots of languages have been already included since several past releases. For nova and many other projects, the translation focus depends on different language teams. Luigi Toscano wrote on 9/12/2016 9:04 PM: > On Friday, 9 September 2016 14:12:51 CEST Matt Riedemann wrote: >> On 9/9/2016 1:58 PM, Ben Swartzlander wrote: >>> On 09/08/2016 08:37 PM, Matt Riedemann wrote: >>>> On 9/8/2016 7:05 PM, Ravi, Goutham wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I was looking for some clarity around backports of bug fixes that >>>>> qualify the stable branch policy [1]. >>>>> <http://docs.openstack.org/project-team-guide/stable-branches.html#appro >>>>> priate-fixes> >>>>> >>>>> >>>>> What is the policy if the fix introduces a new translatable string or >>>>> modifies an existing one? >>>>> >>>>> The guidelines in Release management [2] >>>>> <http://docs.openstack.org/project-team-guide/release-management.html> >>>>> regarding string freeze do not specifically call this scenario out. I >>>>> see that while translatable strings are mostly avoided, some projects >>>>> have been merging changes to stable branches with introduction of new >>>>> translatable strings. >>>>> >>>>> >>>>> >>>>> The question is reminiscent of one posed in the ML a few releases ago >>>>> [3]; >>>>> <http://lists.openstack.org/pipermail/openstack-dev/2015-September/07394 >>>>> 2.html> >>>>> >>>>> >>>>> but applies to stable branches. Should we allow changes to translatable >>>>> strings for bug fixes that matter, or is it better to always deny them >>>>> for the sake of translation accuracy? >>>> The former IMO, a high severity bug fix trumps a translation. Note that >>>> some projects are translated on the stable branches too, I know this is >>>> the case for Nova. >>>> >>>> If it's a user-facing change, like an error message in the API, then it >>>> might require a bit more careful consideration, but if it's just a log >>>> message marked for translation that an end user of the API wouldn't see >>>> anyway, then I think it's fine to backport it. >>> So this stance makes sense to me, but I can't reconcile it with the >>> "hard string freeze" rules. Is the theory that after we release, the >>> string freeze ends for the stable branch, and that the hard string >>> freeze only exists for that 3 week period between RC1 and final release, >>> or is the theory that hard string freeze is always subject to exceptions >>> for "critical" bug fixes? >>> >> I treat it as the former. > Interesting: I'm not a translator in the OpenStack project, but I contribute > as translator to other Free Software communities and I would thought as the > latter as more appropriate. Stable is stable and string changes should be > approved on a case-by-case, otherwise translator's life can be more > complicated especially when the next release is translated. > > But as I said I'm not a translator here. > Currently my suggestion is the latter, not former, and if some exception is needed, then writing and sharing such as http://lists.openstack.org/pipermail/openstack-i18n/2016-September/002402.h… would be nice. However, it seems that there are some more things to be elaborated such as: - Need to identify how many projects are interested in translation especially for hard string freeze in different language teams - Although strings are hard-freezed, some strings will not appropriate to be translatable. It can be from misuse of ungettext() and ungettext_lazy() functions. - Or translators may find source string typos. Should they be included into stable branch? - Notification to exceptional cases to I18n team is needed. - ... I would like to copy this thread to openstack-i18n mailing list, and also discuss those things with many translators to find great solutions. If there is some better idea, please share it :) With many thanks, /Ian

1 0

Stop
by Sonny TADJER 17 Sep '16

17 Sep '16

Stop Sent from my iPad > On 17 Sep 2016, at 13:00, openstack-i18n-request(a)lists.openstack.org wrote: > > Send OpenStack-I18n mailing list submissions to > openstack-i18n(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > or, via email, send a message with subject or body 'help' to > openstack-i18n-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-i18n-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenStack-I18n digest..." > > > Today's Topics: > > 1. Re: First stable/newton branches created (Akihiro Motoki) > 2. Re: First stable/newton branches created (Andreas Jaeger) > 3. [String freeze exception] Horizon > https://review.openstack.org/#/c/371907/ (Akihiro Motoki) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 16 Sep 2016 23:42:32 +0900 > From: Akihiro Motoki <amotoki(a)gmail.com> > To: "Kato, Tomoyuki" <kato.tomoyuki(a)jp.fujitsu.com> > Cc: Andreas Jaeger <aj(a)suse.com>, "openstack-i18n(a)lists.openstack.org" > <openstack-i18n(a)lists.openstack.org> > Subject: Re: [OpenStack-I18n] First stable/newton branches created > Message-ID: > <CALhU9tk1OnDZ7H+HTqrFG=CJh4EZ2_nvX5iadEMgzQWpzbJ+5A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 2016?9?16?????Kato, Tomoyuki<kato.tomoyuki(a)jp.fujitsu.com>????????: > >>> Thanks Andreas for the info. >>> >>> Kato-san, could you take care of it? >>> You can do it yourself or delegate it to someone else, >>> but it is better to do it soon. Otherwise master and stable-newton >>> will be diverged. >> >> Sorry for late response. I wiil work on it from now. > > > No problem. I can help additional prpject branching. > We were just discussing what we can, > Thanks formyour help. > > >> KATO Tomoyuki >> >> >>> >>>> Syncing to Zanata works automatically if there is a stable-newton (note >>>> the "-", Zanata does not allow "/"!) branch. >>> >>> That's what was unclear to me. Thanks. >>> So, the question now is who creates stable-newton version in Zanata. >>> I think only the limited folks can do that. Perhaps Daisy, Kato-san, >> Andreas? >>> In addition to the permission, the tips on creating a Zanata version >>> has not been shared. >>> >>> Akihiro >>> >>> 2016-09-16 14:32 GMT+09:00 Andreas Jaeger <aj(a)suse.com <javascript:;>>: >>>>> On 09/16/2016 04:30 AM, Akihiro Motoki wrote: >>>>> Hi Ian, >>>>> >>>>> 2016-09-16 9:54 GMT+09:00 Ian Y. Choi <ianyrchoi(a)gmail.com >> <javascript:;>>: >>>>>> Hello Andreas and i18n team members, >>>>>> >>>>>> Yesterday (according to UTC), Kato-san and me discussed this topic >> in IRC >>>>>> meeting [1], >>>>>> but we are not sure when we will have stable-newton branch. >>>>>> I think it is time to create stable-newton branch now and Kato-san >> will deal >>>>>> with, >>>>>> but I would like to ask some details to clarify the best timing of >> creating >>>>>> a stable branch. >>>>>> >>>>>> When should i18n team create a stable branch (e.g., stable-newton) in >>>>>> Zanata? >>>>> >>>>> Although I am not familiar with Zanata operations, I think the i18n >>>>> team needs to >>>>> create 'stable-newton' version by branching 'master' version in Zanata >>>>> to inherit >>>>> translation works made in the master version so far. >>>>> >>>>> In my understanding, what we need to do are: >>>>> (a) create stable-newton version in Zanata from master version -> >> i18n team >>>>> (b) release RC1 deliverables and create stable/newton branch in git >>>>> repositories -> each project team and release team >>>>> (c) set up project-config to sync repositories and translations for >>>>> stable/newton -> infra team (I can as well) >>>> >>>> Syncing to Zanata works automatically if there is a stable-newton (note >>>> the "-", Zanata does not allow "/"!) branch. Importing into >>>> stable/newton needs project-config changes. If you would do that, it >>>> would be great! >>>> >>>> >>>>> There is no strict relationship between (a) and (b), and either of >>>>> them can happen first. >>>>> If the timing of (a) and (b) are closer, most translation work in >>>>> 'master' in Zanata are copied into 'stable-newton' version. >>>>> (c) needs to be done after both (a) and (b). >>>> >>>> Indeed, >>>> >>>> Andreas >>>> >>>>>> I thought just after from "Hard StringFreeze" in [2] would be the >> right >>>>>> time, >>>>>> or checking at least Horizon development status (since the focus of >> i18n >>>>>> team now is Horizon related projects) >>>>>> would be needed. (Previously we had I18n cross project liaisons [3].) >>>>> >>>>> To be honest, RC1 release means 'Hard String Freeze'. That's all. >>>>> We can know RC1 release notices by various ways: >>>>> - checking release announcements, >>>>> - checking openstack/releases reviews [5], >>>>> - checking releases.openstack.org [6] >>>>> >>>>> I think we should prepare stable-newton version in Zanata for all >> projects, >>>>> even though most of the i18n team focus on horizon related >> translations. >>>>> >>>>> I am not sure i18n liaisons for horizon related projects work in this >> cycle. >>>>> We have sent no reminder for i18n liaisons... >>>>> In the previous release, I took care of horizon related projects but >>>>> it is beyond >>>>> the role of horizon-i18n liaison and I am not taking care of them >>>>> (except horizon itself). >>>>> >>>>> Horizon RC1 will be shipped in several hours. The team is preparing >>>>> the release now. >>>>> >>>>>> Or should we start gradually the projects merged with >> "topic:create-[release >>>>>> name]" patches, like [4]? >>>>>> >>>>>> [1] >>>>>> http://eavesdrop.openstack.org/meetings/openstack_i18n_ >> meeting/2016/openstack_i18n_meeting.2016-09-15-13.03.html >>>>>> [2] https://releases.openstack.org/newton/schedule.html >>>>>> [3] https://wiki.openstack.org/wiki/CrossProjectLiaisons#I18n >>>>>> [4] https://review.openstack.org/#/q/topic:create-newton >>>>> >>>>> [5] https://review.openstack.org/#/q/project:openstack/releases+ >> path:%255Edeliverables/newton/.* >>>>> [6] https://releases.openstack.org/newton/index.html >>>>> >>>>> Thanks, >>>>> Akihiro >>>>> >>>>>> >>>>>> >>>>>> With many thanks, >>>>>> >>>>>> /Ian >>>>>> >>>>>> Andreas Jaeger wrote on 9/16/2016 3:35 AM: >>>>>>> >>>>>>> Could somebody please set up stable-newton branches for those >> projects >>>>>>> that should get translations of them, please? >>>>>>> >>>>>>> With RC1 today, projects are creating stable/newton branches now, >>>>>>> >>>>>>> Andreas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenStack-I18n mailing list >>>>>> OpenStack-I18n(a)lists.openstack.org <javascript:;> >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >>>> >>>> >>>> -- >>>> Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: >> jaegerandi >>>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany >>>> GF: Felix Imend?rffer, Jane Smithard, Graham Norton, >>>> HRB 21284 (AG N?rnberg) >>>> GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 >> A126 >

1 0

[String freeze exception] Horizon https://review.openstack.org/#/c/371907/
by Akihiro Motoki 17 Sep '16

17 Sep '16

Hi i18n team, I would like to request a string freeze exception for horizon: https://review.openstack.org/#/c/371907/ which fixes https://bugs.launchpad.net/horizon/+bug/1624197 . It is small enough and can be accepted. Can we move this forward? This patch allows translators to control the word order in delete confirm forms. Currently "You have selected: " and selected items are concatenated and in some language the selected items need to be placed first. Thanks, Akihiro

3 2