- OpenStack-I18n - lists.openstack.org

[all][i18n] Proposed change for consistent setup of translation - up for review
by Andreas Jaeger 11 Jan '16

11 Jan '16

Projects that want to have translations, need to setup their repository in very specific ways which lead to quite a few questions from some of you and also quite different solutions. Let's make this easier - and consistent. I've written a spec that aims to provide a consistent set up for the repositories and ask for your review and comments on it: https://review.openstack.org/#/c/262545/ 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

1 0

Re: [Openstack-i18n] How do we manage glossary - requirements priorities
by Akihiro Motoki 11 Jan '16

11 Jan '16

Thanks for initiating the effort. 2016-01-11 18:36 GMT+09:00 Ying Chun Guo <guoyingc(a)cn.ibm.com>: > Hello, team > > There are three possible solutions to manage glossaries and their > translations. > All of these solutions have their advantages and disadvantages. > I think we should prioritize the requirements firstly, then we make the > choice based on the requirements. > Here I list some requirements. > I would like to suggest to distinguish "master glossary" (in the source language) and "per-language glossary" in this discussion. Theoretically speaking, each language team can have its own glossary, but IIUC Zanata glossary does not allows it and we need to have a common glossary entries. As the assumption of this discussion, should we assume the current enabled feature in Zanata or can we assume to enhancing Zanata? I would suggest to distinguish 'requirements' and the current limitation of Zanata. 'requirement' should not have assumption based on 'the current limitation of Zanata'. Now, I am looking through the listed items. #0 each language team can manage their glossary without 'admin' role. At least, language coordinator and reviewers should be allowed to do it. To me, this is the top priority "must to have". > #1. Save glossaries in i18n repo "nice to have" "master" or "per-language"? Based on #2 below, it seems "master glossary". > #2. Translate and review with Zanata editor, and enable the auto sync > between Zanata editor and i18n repo. In #2, it seems two things are mixed. The first part "Translate and review with Zanata editor", yes it is a requirement. The second part is just a process. It is not a requirement, i.e., "nice to have". > #3. View comments while translating "Must to have" (as the second priority) I believe it is "Must to have" but it is not a top priority because the top priority to me is that each language is allowed to maintain their glossary without 'admin' privilege. > #4. Review the new added glossary by Gerrit "not necessary" I am not sure this needs to be done in Gerrit. If we have a way to add a new entry in Zanata, it is sufficient as well. I am not sure what assumption you have. > #5. View the list of glossaries and their comments in i18n documents. "not necessary" I don't think it is a requirement. I hope the list of glossary on Zanata instead as Transfix does. When we go to "Glossary" link at the top of Zanata UI https://translate.openstack.org/glossary/view.seam, we see a list of languages but when we click a language name, we will get a list of members of each language team. It is a confusing behavior and we expect a glossary in each language. > #6. Keep the history of glossary translations and discussions. "must to have" (as the second priority) Yes. this is important! > > Please let me know your thoughts to these requirements. > You can add comment "Must support", "good to have", and "not necessary" to > each requirement, > and order these requirements by the priority in your mind. > If you have other requirements, feel free to add. /FYI/ I abandoned my reviews to keep my review list small. Feel free to restore them if necessary even after this discussion have a consensus. Thanks, Akihiro > > For your reference, here are the three possible solutions: > > - Solution 1 Save glossaries in pot file and translations in po files. > The current solution in repo: openstack/i18n > Support requirement #1 , #2 and #4 > ( @Alex, please help to verify if #3 and #6 could be satisfied in this > solution.) > > - Solution 2 Save glossaries in rst file and translations in po files. > https://review.openstack.org/#/c/258924/ > Support requirement #1, #2, and #4, #5 > > - Solution 3 Save glossaries in YAML file and translations in YAML files. > https://review.openstack.org/#/c/261767/ > https://review.openstack.org/#/c/262710/ > Support requirement #1, #3 and #4, #6 > > Your input will help us to make a team decision. > Thank you. > Best regards > Ying Chun Guo (Daisy) > > > Akihiro Motoki <amotoki(a)gmail.com> wrote on 2016/01/05 19:09:09: > >> From: Akihiro Motoki <amotoki(a)gmail.com> >> To: Ying Chun Guo/China/IBM@IBMCN >> Cc: "openstack-i18n(a)lists.openstack.org" >> <Openstack-i18n(a)lists.openstack.org> >> Date: 2016/01/05 19:10 >> Subject: Re: [Openstack-i18n] How do we manage glossary? >> >> 2016-01-05 18:00 GMT+09:00 Ying Chun Guo <guoyingc(a)cn.ibm.com>: >> > Thank you for the patch, Akihiro. >> > I think it's easier to discuss in email. >> > So I copied your comments in your patch here. >> > >> >> Expected workflow: >> >> * add an entry to the master glossary: >> >> - Update glossary/master.yaml and review it on gerrit >> >> - Once approved, glossary-tool sync will update per-language glossary >> >> files and propose the update to gerrit (jenkins jos) >> > >> > In your design, when the changes to master.yaml is approved, how to >> > trigger >> > the jenkins job ? using a tag ? >> > I think we could add one more action in this Jenkins job: automatically >> > send >> > an email to i18n to notify that the glossary is changed. >> >> We can use 'post' pipeline to trigger some jobs when each change is >> merged. >> >> >> * update per-language glossary: >> >> - Each language team upload a proposed glossary to gerrit. A language >> >> team >> >> members review it and once they have a consensus i18n core reviewer >> >> merges >> >> it into the repository. >> >> - Once approved, a corresponding glossary PO file is generated and >> >> uploaded to Zanata. (glossary-tool write-po and jenkins job) >> > >> > In your design, translators will not use translation editor in Zanata to >> > translate glossary. >> > Translators will propose the glossary translation to gerrit. >> > I don't know if translators have enough training to commit a patch. >> > They may understand how to use Zanata more than how to use gerrit. >> > There is no commands to support uploading glossary to Zanata. >> > So the action to upload po files have to be executed manually. >> >> I think uploading glossary can be done by Jenkins job triggered by >> 'post' job as well. >> I agree that translators are familiar with Zanata rather than Gerrit >> to some extent. >> >> However, my question is still how to keep discussion contexts (or >> history/background). >> It seems Zanata history is associated with Zanata internal resource ID. >> I am afraid it can be easily lost and we cannot recover it :-( >> >> > How do you think if we change to: >> > - Update glossary/master.yaml and review it on gerrit. >> > - Once approved, glossary-tool sync will update per-language glossary >> > files >> > and propose the update to gerrit (jenkins jos). >> > - The jenkins job will upload pot file in Zanata. >> > - The jenkins job will send email to i18n to notify the change. >> > - Translators log in to Zanata to translate. >> > - Jenkins job download po files to i18n repository. >> > - Zanata admin automatic update Zanata glossary. >> >> Again, how can we maintain discussion contexts? >> >> On the other hand, I might be thinking "context" too much. >> If we go to the above way you mentioned, >> I think we need to maintain discussion contexts in other places. >> If the team suggests to do so, I am okay. >> >> Japanese team actually maintains it in OpenStack wiki and it works mostly >> well >> except that we need to sync glossary manually, but it might be a small >> thing >> compared to keep "context". Keeping "context" will save time to explain >> why >> we choose THIS in our current glossary. If we do not have it, we need to >> explain same things to new contributors again and again, and this >> will increase >> the barrier to new contributors. >> >> >> * syntax when a review is proposed >> >>- 'glossary-tool' check verifies if YAML data is valid. It can be a part >> >> of >> >> pep8 target. >> > >> > Good to have syntax check. >> > >> > BTW, how do you think the advantage of YAML file, comparing with po and >> > pot >> > files? >> > Because if we use po and pot files directly, we could put "note" as >> > comments >> > in pot files. >> > Do you want "note" also be translated ? >> >> The only reason is YAML file is human-friendly and easy to edit by >> text editors. >> I don't think it is a good idea to edit PO file directly. >> The format is not human-friendly and we can easily make mistakes in >> editing PO files. >> >> "note" in a PO file will be overridden if the glossary is downloaded >> from Zanata. >> This means we need to manage PO files directly in our git repo. >> I don't think maintaining PO files is more difficult than maintaining >> YAML files. >> >> >> Finally, I would like to purge ancient glossary on Zanata as soon >> aspossible. >> The current glossary harms translation and provides no value. >> >> Akihiro >> >> >> > >> > Regards >> > Daisy >> > >> > >> > Akihiro Motoki <amotoki(a)gmail.com> wrote on 2016/01/05 07:05:51: >> > >> >> From: Akihiro Motoki <amotoki(a)gmail.com> >> >> To: Ying Chun Guo/China/IBM@IBMCN >> >> Cc: "openstack-i18n(a)lists.openstack.org" >> >> <Openstack-i18n(a)lists.openstack.org> >> >> Date: 2016/01/05 07:07 >> >> Subject: Re: [Openstack-i18n] How do we manage glossary? >> > >> >> >> >> Hi Daisy and the team, >> >> >> >> 2015-12-17 19:35 GMT+09:00 Ying Chun Guo <guoyingc(a)cn.ibm.com>: >> >> > Hi, Akihiro >> >> > >> >> > Please let me know your comments to >> >> > https://review.openstack.org/258924 >> >> >> >> I commented your above review. >> >> >> >> I proposed a counter proposal https://review.openstack.org/261767. >> >> This is just an idea. I am open to the input. >> >> >> >> Comments inline below. >> >> >> >> > Answers to your question: >> >> > >> >> > 1. Context >> >> > >> >> > The current solution in my patch could not satisfy this requirement >> >> > about >> >> > context. >> >> > If we want to put context to glossary, we need to develop our own >> >> > extension >> >> > of sphinx-build. >> >> > How do you think the priority to support context ? >> >> >> >> IMHO supporting contexts is important to make discussion on glossary >> >> productive. >> >> As you can see in Japanese glossary on OpenStack wiki [1], I believe >> >> that discussion contexts >> >> are important for further discussions and it also helps new >> >> contributors understand the background. >> >> >> >> In my proposal https://review.openstack.org/261767, >> >> we maintain all contexts in YAML glossary files. >> >> >> >> > 2. Process >> >> > >> >> > If people want to change the glossary, e.g. add, update, change the >> >> > comments, add coments >> >> > following process is designed. >> >> > >> >> > a> the requestor submits a patch to i18n repo >> >> > b> core team approve the patch >> >> > c> the auto uploading process is triggered. terminology.pot is >> >> > uploaded >> >> > to >> >> > Zanata for translation >> >> > d> translators finish translation >> >> > e> Zanata admin manually patch terminology.pot and its translationpo >> >> > files, >> > >> >> > and upload to Zanata >> >> >> >> IMO the glossary needs to be reviewed more carefully compared to >> >> regular translations. >> >> In regular translations, all translated strings are imported, but for >> >> glossary it is better that >> >> only reviewed strings are imported. Another choice is to use gerrit >> >> for the glossary review. >> >> My proposal https://review.openstack.org/261767 implements the latter >> >> option. >> >> >> >> Thought? >> >> >> >> Thanks, >> >> Akihiro >> >> >> >> > >> >> > Best regards >> >> > Ying Chun Guo (Daisy) >> >> > >> >> > >> >> > Akihiro Motoki <amotoki(a)gmail.com> wrote on 2015/12/02 02:29:44: >> >> > >> >> >> From: Akihiro Motoki <amotoki(a)gmail.com> >> >> >> To: "openstack-i18n(a)lists.openstack.org" >> >> >> <Openstack-i18n(a)lists.openstack.org> >> >> >> Date: 2015/12/02 02:32 >> >> >> Subject: [Openstack-i18n] How do we manage glossary? >> >> > >> >> >> >> >> >> Hi team, >> >> >> >> >> >> Recently we added the glossary to the i18n repo [1]. >> >> >> I wonder how we can manage the glossary and am sending this mail. >> >> >> The glossary can be referred to in Zanata, so it would be useful. >> >> >> >> >> >> Mainly I have two questions. >> >> >> >> >> >> The first point is what is the expected process to manage the >> >> >> glossary. >> >> >> How can we update the glossary? >> >> >> When is it uploaded to Zanata for translations? >> >> >> >> >> >> The second point is how we can have the context. >> >> >> I think the second point is also important. >> >> >> Each entry in our glossary has some background, for example >> >> >> why we reach the current consensus. >> >> >> This kind of context is important to discuss for further >> >> >> improvements. >> >> >> >> >> >> I updated the glossary for Japanese translation last week >> >> >> and I added various description about backgrounds of the glossary. >> >> >> I feel it is important to keep the context. >> >> >> How can we manage the context? >> >> >> >> >> >> I don't have a good idea now. >> >> >> I would like to raise these questions for broader discussion. >> >> >> >> >> >> Thanks, >> >> >> Akihiro >> >> >> >> >> >> [1] http://git.openstack.org/cgit/openstack/i18n/tree/i18n >> >> >> >> >> >> _______________________________________________ >> >> >> Openstack-i18n mailing list >> >> >> Openstack-i18n(a)lists.openstack.org >> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >> >> >> >> >> > >> >> >> > >> >

1 0

Austin OpenStack Summit call-for-papers is open
by Ying Chun Guo 10 Jan '16

10 Jan '16

Hello, team The next OpenStack Summit will take place on April 25-29 in Austin, Texas, US. The Call for Papers is opened and will close on Feb 1st. You could find details on the tracks and process on the official page: https://www.openstack.org/summit/austin-2016/call-for-speakers/. I think following tracks are much related with our work. You are welcomed to submit speech proposals to these tracks. * Project Updates * How to Contribute * Upstream Development * Working Groups The track "Working Groups" is special. It is for collaborative working sessions rather than presentations. It will be in smaller rooms and video record will not be served. We can organize I18n/translations related working sessions in this track. If you have any speeches or discussion topics related with I18n/translations, you can contact with me. I'm happy to help review and schedule. BTW, the travel support program is opened at: https://www.openstack.org/summit/austin-2016/austin-and-travel/#travel-supp… . The deadline is Feb 9. Thank you. Best regards Ying Chun Guo (Daisy)

1 0

Re: [Openstack-i18n] Czech translation error
by Akihiro Motoki 07 Jan '16

07 Jan '16

I am not sure it is a bug of the source string. It works as the source language. The similar example is shown in the gettext documentation I quoted in the first mail. Apart from the warning you mentioned, after we change msgstr[0] to contain %s in a translation, the error disappears. IMHO, it is a bug of GNU gettext. On the other hand, I agree it is less confusing if the source string contains %s. Feel free to file a bug to horizon with a background. Akihiro 2016-01-07 18:19 GMT+09:00 Ying Chun Guo <guoyingc(a)cn.ibm.com>: > Hi, Akihiro > > It is a bug in the source code, isn't it ? > I don't see the translations are wrong. > > msgid is "Instance launched." > We cannot simply add %s to msgstr[0]. > Zanata will report a warning: Unexpected variable: %s > > I think the source string "Instance launched." should add %s firstly. > "Instance launched." should be changed to "Instance %s launched." > And then, the translation msgstr[0] should add %s correspondingly. > > Best regards > Ying Chun Guo (Daisy) > > > Akihiro Motoki <amotoki(a)gmail.com> wrote on 2016/01/07 01:44:42: > >> From: Akihiro Motoki <amotoki(a)gmail.com> >> To: "openstack-i18n(a)lists.openstack.org" >> <Openstack-i18n(a)lists.openstack.org> >> Date: 2016/01/07 01:46 >> Subject: [Openstack-i18n] Czech translation error > >> >> Hi Czech language team and i18n Zanata admin, >> >> Horizon translation import is broken due to Czech translation. >> This blocks all translation imports of horizon. >> Could you fix it? >> >> https://review.openstack.org/#/c/259677 >> >> The error is like this: >> http://logs.openstack.org/77/259677/15/check/gate-horizon-dsvm- >> integration/e5ed03e/logs/devstacklog.txt.gz#_2016-01-02_17_55_04_608 >> 2016-01-02 17:55:04.608 | CommandError: Execution of msgfmt failed: >> /opt/stack/new/horizon/openstack_dashboard/locale/cs/LC_MESSAGES/ >> djangojs.po:655: >> number of format specifications in 'msgid_plural' and 'msgstr[0]' does >> not match >> 2016-01-02 17:55:04.608 | msgfmt: found 1 fatal error >> >> The error point is: >> https://review.openstack.org/#/c/259677/15/openstack_dashboard/ >> locale/cs/LC_MESSAGES/djangojs.po >> >> I think we need to add %s to msgstr[0] to avoid msgfmt error. >> >> #, python-format >> msgid "Instance launched." >> msgid_plural "%s instances launched." >> msgstr[0] "Instance spuštěna. >> msgstr[1] "Spuštěny %s instance." >> msgstr[2] "Spuštěno %s instancí." >> >> >> BTW, I am not sure this is valid according to GNU gettext documentation >> [1], >> but msgfmt actually does not support this form. >> In the example of [1], msgid does not contain %s but all msgstr[n] contain >> %s. >> Although there is no explicit description, %s must be contained in all >> msgstr[n]. >> To avoid confusion, it is better to contain %s in 'msgid' (singular >> form) as well. >> >> [1] https://www.gnu.org/software/gettext/manual/html_node/ >> Translating-plural-forms.html >> >> >> Akihiro >> >> _______________________________________________ >> Openstack-i18n mailing list >> Openstack-i18n(a)lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >

3 2

Czech translation error
by Akihiro Motoki 07 Jan '16

07 Jan '16

Hi Czech language team and i18n Zanata admin, Horizon translation import is broken due to Czech translation. This blocks all translation imports of horizon. Could you fix it? https://review.openstack.org/#/c/259677 The error is like this: http://logs.openstack.org/77/259677/15/check/gate-horizon-dsvm-integration/… 2016-01-02 17:55:04.608 | CommandError: Execution of msgfmt failed: /opt/stack/new/horizon/openstack_dashboard/locale/cs/LC_MESSAGES/djangojs.po:655: number of format specifications in 'msgid_plural' and 'msgstr[0]' does not match 2016-01-02 17:55:04.608 | msgfmt: found 1 fatal error The error point is: https://review.openstack.org/#/c/259677/15/openstack_dashboard/locale/cs/LC… I think we need to add %s to msgstr[0] to avoid msgfmt error. #, python-format msgid "Instance launched." msgid_plural "%s instances launched." msgstr[0] "Instance spuštěna. msgstr[1] "Spuštěny %s instance." msgstr[2] "Spuštěno %s instancí." BTW, I am not sure this is valid according to GNU gettext documentation [1], but msgfmt actually does not support this form. In the example of [1], msgid does not contain %s but all msgstr[n] contain %s. Although there is no explicit description, %s must be contained in all msgstr[n]. To avoid confusion, it is better to contain %s in 'msgid' (singular form) as well. [1] https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-fo… Akihiro

4 4

IRC meeting today
by Ying Chun Guo 06 Jan '16

06 Jan '16

Hello, team I hope you had a good new year holiday. We will have our first IRC meeting in 2016 today, at 0600UTC in #openstack-meeting. I'm going to cover following topics: * Glossary management process discussion * Open discussions Feel free to propose other topics if you like. Best regards Ying Chun Guo (Daisy)

2 1

Re: [Openstack-i18n] How do we manage glossary?
by Kato, Tomoyuki 05 Jan '16

05 Jan '16

> >> Expected workflow: > >> * add an entry to the master glossary: > >> - Update glossary/master.yaml and review it on gerrit > >> - Once approved, glossary-tool sync will update per-language glossary > >> files and propose the update to gerrit (jenkins jos) > > > > In your design, when the changes to master.yaml is approved, how to trigger > > the jenkins job ? using a tag ? > > I think we could add one more action in this Jenkins job: automatically send > > an email to i18n to notify that the glossary is changed. > > We can use 'post' pipeline to trigger some jobs when each change is merged. I'm not fully contexted, but generally agree to 'post' pipeline idea. KATO Tomoyuki

1 0

Fw: [OpenStack-docs] Travel support for Summit, April 25-29, Austin, TX
by Ying Chun Guo 05 Jan '16

05 Jan '16

Hi, team If you need the travel support for Austin Summit, you could apply now. Best regards Ying Chun Guo (Daisy) ----- Forwarded by Ying Chun Guo/China/IBM on 2016/01/05 17:01 ----- Anne Gentle <annegentle(a)justwriteclick.com> wrote on 2016/01/05 01:43:00: > From: Anne Gentle <annegentle(a)justwriteclick.com> > To: "openstack-docs(a)lists.openstack.org" <openstack-docs(a)lists.openstack.org> > Date: 2016/01/05 01:45 > Subject: [OpenStack-docs] Travel support for Summit, April 25-29, Austin, TX > > Hi all, > Want to be sure that documentarians know about the travel support > program to get contributors to the Summit. Read all about it and apply here: > > https://www.openstack.org/summit/austin-2016/austin-and-travel/#travel-supp… > > Thanks, > Anne > > -- > Anne Gentle > Rackspace > Principal Engineer > www.justwriteclick.com_______________________________________________ > OpenStack-docs mailing list > OpenStack-docs(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs

1 0

Re: [Openstack-i18n] How do we manage glossary?
by Akihiro Motoki 05 Jan '16

05 Jan '16

Hi Daisy and the team, 2015-12-17 19:35 GMT+09:00 Ying Chun Guo <guoyingc(a)cn.ibm.com>: > Hi, Akihiro > > Please let me know your comments to https://review.openstack.org/258924 I commented your above review. I proposed a counter proposal https://review.openstack.org/261767. This is just an idea. I am open to the input. Comments inline below. > Answers to your question: > > 1. Context > > The current solution in my patch could not satisfy this requirement about > context. > If we want to put context to glossary, we need to develop our own extension > of sphinx-build. > How do you think the priority to support context ? IMHO supporting contexts is important to make discussion on glossary productive. As you can see in Japanese glossary on OpenStack wiki [1], I believe that discussion contexts are important for further discussions and it also helps new contributors understand the background. In my proposal https://review.openstack.org/261767, we maintain all contexts in YAML glossary files. > 2. Process > > If people want to change the glossary, e.g. add, update, change the > comments, add coments > following process is designed. > > a> the requestor submits a patch to i18n repo > b> core team approve the patch > c> the auto uploading process is triggered. terminology.pot is uploaded to > Zanata for translation > d> translators finish translation > e> Zanata admin manually patch terminology.pot and its translation po files, > and upload to Zanata IMO the glossary needs to be reviewed more carefully compared to regular translations. In regular translations, all translated strings are imported, but for glossary it is better that only reviewed strings are imported. Another choice is to use gerrit for the glossary review. My proposal https://review.openstack.org/261767 implements the latter option. Thought? Thanks, Akihiro > > Best regards > Ying Chun Guo (Daisy) > > > Akihiro Motoki <amotoki(a)gmail.com> wrote on 2015/12/02 02:29:44: > >> From: Akihiro Motoki <amotoki(a)gmail.com> >> To: "openstack-i18n(a)lists.openstack.org" >> <Openstack-i18n(a)lists.openstack.org> >> Date: 2015/12/02 02:32 >> Subject: [Openstack-i18n] How do we manage glossary? > >> >> Hi team, >> >> Recently we added the glossary to the i18n repo [1]. >> I wonder how we can manage the glossary and am sending this mail. >> The glossary can be referred to in Zanata, so it would be useful. >> >> Mainly I have two questions. >> >> The first point is what is the expected process to manage the glossary. >> How can we update the glossary? >> When is it uploaded to Zanata for translations? >> >> The second point is how we can have the context. >> I think the second point is also important. >> Each entry in our glossary has some background, for example >> why we reach the current consensus. >> This kind of context is important to discuss for further improvements. >> >> I updated the glossary for Japanese translation last week >> and I added various description about backgrounds of the glossary. >> I feel it is important to keep the context. >> How can we manage the context? >> >> I don't have a good idea now. >> I would like to raise these questions for broader discussion. >> >> Thanks, >> Akihiro >> >> [1] http://git.openstack.org/cgit/openstack/i18n/tree/i18n >> >> _______________________________________________ >> Openstack-i18n mailing list >> Openstack-i18n(a)lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n >> >

2 1

Re: [Openstack-i18n] Transifex
by Ian Y. Choi 22 Dec '15

22 Dec '15

Hello Daisy, Thank you so much for your kind explanation. I agree that all of translation data are successfully moved to Zanata, and I have no objection to remove current Transifex not to be confused for OpenStack translation contributor candidates. I just worried that some guys might want to see previous Transifex history: who contributed to OpenStack translations later, since, the author of translation results from Transifex to Zanata is "OpenStack Infra", not actual translators, as far as I know. However, I also think that it is very difficult to keep all the history to public. For my OpenStack translation stuff, I do not need Transifex any more. So if other translators also do not need to see to track previous translators in Transifex, then there is no more additional reason to remove Transifex except querying statistics. And one more idea: although some previous translators are not regarded as ATC, I think it would be much better to mention their Transifex ID (at least) to acknowledge their previous contribution or credit on somewhere, such as OpenStack wiki. Let's discuss on today IRC meeting :) With many thanks, /Ian Ying Chun Guo wrote on 12/17/2015 2:39 PM: > > Ian Y, > > I will not use the official i18n repo to store those materials. > I plan to store it in a personal repo in github, > just to keep the history. > > We have moved all data into Zanata while we migrated to Zanata in > September. > 4 months passed, we didn't get any complains about any missing data. > We could be sure that all data have been moved to the new tool. > So it's not that necessary to back up. > > The only reason to support to not delete OpenStack from Transifex is that: > it's easy to query the contribution data in any certain period through > the web UI of Transifex. > If we remove OpenStack from Transifex, we will lost the ability to query. > I could export the contribution data for a certain period, for > example, the last 3 years, from Transifex, > and store the export data somewhere. > But I will lost the ability to query any periods, for example, the > data from 2015.4-2015.10 will not be able to get. > > So we could discuss whether we need this ability in the meeting today. > If we don't need, Transifex is no use for us. We could delete it safely. > > Best regards > Ying Chun Guo (Daisy) > > > "Ian Y. Choi" <ianyrchoi(a)gmail.com> wrote on 2015/12/17 12:21:34: > > > From: "Ian Y. Choi" <ianyrchoi(a)gmail.com> > > To: Ying Chun Guo/China/IBM@IBMCN, Andreas Jaeger <aj(a)suse.com> > > Cc: Robert Simai <robert.simai(a)suse.com>, > openstack-i18n(a)lists.openstack.org > > Date: 2015/12/17 12:22 > > Subject: Re: [Openstack-i18n] Transifex > > > > Hello Andreas, > > > > I am copying & pasting from Andreas's comment to this thread: > > > > +++ > > "Sorry, let me clarify this again: > > * ATC is one year (voting rights for i18n) > > * Free passes for OpenStack conference is 6 months > > > > For ATC, you could take a one time snapshot as well now - going back > > to 1st of April, instead of saving it for later," > > > > > > => Thank you so much for your nice clarification on ATC status and > > summit free passes. > > > > We would vote this issue (removing on Transifex site) on today's IRC > > meeting, and yes. > > We need contribution statistics data from Transifex, and I agree that > > we can query and save Transifex statistics data (from April 1 2015 > > to now) and later > > we would merge this data with Zanata statistics data on next April. > > > > And I am not sure exactly, but we might use openstack/i18n repo to > > store Transfex related data > > into a specific branch, not a master branch. > > > > > > With many thanks, > > > > /Ian > > > > > > Ying Chun Guo wrote on 12/17/2015 1:21 AM: > > If we don't need the contribution data in Transifex, I think we > > could remove it. > > > > As to the back up, it's a personal habit. I just want to keep it as > > the history. > > I will use a repo in github to store the documents, including an > > Excel file with the contribution statistic data. > > > > Best regards > > Ying Chun Guo (Daisy) > > > > > > -----Andreas Jaeger <aj(a)suse.com> wrote: ----- > > > > >To: "Ian Y. Choi" <ianyrchoi(a)gmail.com>, Robert Simai > > ><robert.simai(a)suse.com> > > >From: Andreas Jaeger <aj(a)suse.com> > > >Date: 12/16/2015 09:59PM > > >Cc: openstack-i18n(a)lists.openstack.org > > >Subject: Re: [Openstack-i18n] Transifex > > > > > >On 2015-12-16 14:45, Andreas Jaeger wrote: > > >> On 2015-12-16 14:34, Ian Y. Choi wrote: > > >>> Hello Robert, > > >>> > > >>> As far as I remember, on the last i18n irc meeting (Dec 03 2015 +6 > > >UTC), > > >>> we discussed this issue. > > >>> > > >>> During the meeting, meeting attendees found that querying to > > >Transifex > > >>> statistics data > > >>> is needed to check ATC status for the next OpenStack release, > > >Mitaka. > > >> > > >> ATC status is handed out only for people active in the current > > >release, > > >> so for the next summit in Austin, only for people that were active > > >in > > >> Mitaka time frame. And since we used Zanata for all of Mitaka, > > >there's > > >> no need to query transifex IMO. > > >> > > >> Katamo is wrong with ATC status for one year, this has changed, > > > > > >See > > >https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstac > > >k-summit/ > > >with information for Tokyo summit (1st of April was cut-off-date), > > > > > >Andreas > > >-- > > > Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter: 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 > > > > > > > > >_______________________________________________ > > >Openstack-i18n mailing list > > >Openstack-i18n(a)lists.openstack.org > > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-i18n > > > > > > >

5 5