06:00:50 #startmeeting OpenStack I18n Meeting 06:00:51 Meeting started Thu Dec 3 06:00:50 2015 UTC and is due to finish in 60 minutes. The chair is Daisy. Information about MeetBot at http://wiki.debian.org/MeetBot. 06:00:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 06:00:56 The meeting name has been set to 'openstack_i18n_meeting' 06:01:17 Hello, Daisy. How are you going? :) 06:01:25 Hi, ianychoi 06:01:40 I'm good. How about you ? 06:02:07 o/ 06:02:11 Good, except that lots of my company work is coming.. :) 06:02:19 Hello, Kato-san! 06:02:29 I didn't notice my mail didn't send out yesterday. Something is wrong with my mail server. Sorry for the late notice. 06:02:38 hello, ianychoi 06:02:57 Daisy: np 06:03:09 OK. Let's start. 06:03:10 hi 06:03:22 Hi, aeng! 06:03:22 Welcome, aeng 06:03:38 #topic Discussion: Bug management process in Launchpad 06:03:55 https://review.openstack.org/#/c/246256 06:04:16 In this patch, Akihiro changed the structure. 06:04:53 In doc/source/bug_report.rst, it's quick simple. So guide people to report bugs to lunchpad. 06:05:13 And a new rst file is added: doc/source/bug_process.rst 06:06:01 In bug_process.rst, there are several questions raised by Akihiro. 06:06:50 I don't know if I'm right. Just feeling we could follow the usually bug processing of Launchpad to manage. 06:07:23 There are a few questions we should discuss here: 06:07:48 How can we catagorize bugs written in a language nobody can read? 'unknown' tag? 06:08:12 Do you think we could receive such bugs written in a language that nobody can read ? 06:08:56 I would its very rare but its possible given its an open community 06:09:12 I don't know if it would happen. Because there may be some non-English bugs reporting to translations. If they are translations, there might be some translators who can read the bugs. 06:09:31 agree. Not unless only 1 translators in that language 06:10:03 But regardless, there's tools to convert it english. 06:10:52 Good idea, aeng. We could use Google translate to translate, maybe . 06:10:52 what tag we are using now for lets say Japanese bug? 06:10:53 hehe 06:11:04 Nice :) 06:11:07 Like Japanese 06:11:11 Auto-language detection 06:12:17 I would say if nobody can read, reply to the reporter to convert it to English, or we can convert to English and then decide what category it goes to 06:12:32 Yes, good point. 06:12:46 Another question is whether we need to create a bug team. 06:12:49 agree 06:13:16 katomo: are there a bug team in doc team who are responsible to handle bug reports ? 06:13:32 katomo: or all team members could handle bug reports ? 06:13:37 none 06:13:46 so all members could. 06:13:52 I like this answer. 06:14:03 there is a defined bugs team, which is freely join :) 06:14:22 so we don't want complicate. Let's open it to all team. 06:14:30 But, Docs cores take care bug triage process, and follow up 06:14:31 By the way, I have one question related to this. Let's suppose that if one bug reporter posts openstack-manuals launchpad for translation errors. Then, should we move this bug to openstack-i18n launchpad? or use "affects project" functionality? 06:15:03 I am asking it because.. we might need to use the same bug status as openstack-manuals.. if we use "affects project" functionality. 06:15:16 Daisy: agree to open to all 06:16:02 katomo: could you answer ianychoi question ? If a bug is related to other projects, how to handle it ? 06:16:14 ianychoi: yes, need change "affects project" 06:16:35 so both bug's status needs to be in sync 06:16:41 ? 06:16:52 katomo: usually, shall we keep the bugs open in our project if the root cause is by other projects ? 06:17:09 aeng: yes, sync automatically 06:17:49 aeng: both or either, If affect both, take cake both. If affect only i18n, simply move to i18n (become deleted from docs) 06:18:03 ok. 06:18:11 That's much clear. 06:18:35 so I will write bug-processing.rst and hope we could merge this patch soon. 06:19:08 Any questions to bug process ? 06:19:22 And.. about priority? 06:19:45 a good question. 06:19:57 I think I18n core team could decide. 06:20:21 because i18n core team will do the bug triage, and define the priority. 06:20:36 Yes, good :) 06:20:43 make sense since they are doing triage 06:20:51 Next topic 06:21:02 #topic Discussion: Glossary management process 06:21:37 The current status is: glossary is in pot format and it is stored in our repo. 06:22:16 The synchronization jobs are not enable because i18n.pot is different from other projects. It's not generated. 06:23:01 sync job between the file and Zanata? 06:23:05 At the beginning, I planned to change the job scripts to upload/download po and pot by force, whether i18n.pot is changed or not. 06:23:10 aeng: Yes 06:23:41 But I didn't commit such changes because I don't like it. 06:24:12 don't like? 06:24:21 I think, the upload/download actions should be taken only when i18n.pot is changed. 06:24:29 Actually I do not the glossary process in Zanata, but any language coordinators can edit glossaries in Zanata? 06:24:56 s/the/know/ 06:25:05 ianychoi, anyone with "glosasrist" role can edit any language of translation in glossary 06:25:08 So I'm trying to find a way to determine whether i18n.pot is changed. 06:25:34 okay 06:25:40 Thanks, aeng. 06:25:44 If i18n.pot is changed, the upload action should be taken. If I18n.pot is not changed, it should not be uploaded. 06:26:00 how is the i18n.pot being changed? 06:26:13 manually commit to git and create pull request? 06:26:45 i18n.pot is manually edited. It contains all the glossaries. 06:27:03 How about zuul job? 06:27:04 manually edited by translators? 06:27:14 Yes, aeng 06:27:18 what is zuul job ? 06:27:37 katomo: can you share me some links ? 06:27:39 gate jobs 06:27:43 ok, perhaps we should stop doing that manual editing. With Zanata 3.8.0, they can edit it straight in Zanata 06:27:46 jenkins 06:28:00 aeng: that's the point. 06:28:01 i.e. When we commit glossary to i18n repo, Jenkins upload the glossary to Zanata 06:28:52 katomo, good point. Jenkins should be able to hookup to git commit 06:28:57 as, not a daily job 06:29:21 yeah, we use github to fire webhook to jenkins 06:29:49 But Glossary management feature will be release in Zanata 3.8.0, and we are planning to have it ready before Christmas. 06:29:51 I do not know some details of automated jobs, but git hook would be a good to take care of this I think. 06:29:56 As aeng said: in Zanata 3.8 which will be released before Christmas, there will be a feature in Zanata: glossarist could add and edit glossaries. 06:30:13 so all these problems should be gone 06:30:19 No, aeng 06:30:38 There is no way for us to upload/download the glossaries and stored in our git. 06:30:48 ah... 06:30:53 aeng: then, i18n pot files are managed by Zanata web UI, and can we download i18n.pot file from Zanata UI from 3.8.0? 06:31:08 or stored to somewhere on git.... 06:31:17 ianychoi, good point. We are discussing export feature now for glossary 06:31:27 not in the plan yet 06:32:01 also, we need review process for glossary change 06:32:34 *glossary itself, not a glossary translation 06:32:54 If we choose to use Zanata to manage our glossaries, we don't need git to store them and we don't need jobs to upload and download them. If we use git to store the glossaries, we cannot use the glossary editor of Zanata, we will define our own process and then, after glossaries are changed, I need to manually upload glossaries in a csv file. 06:33:18 Not sure if I describe clearly. 06:33:24 Just two opitions 06:33:27 very clearly 06:33:40 hm 06:33:42 so clear :) 06:33:55 one is to use Zanata glossary management process, the other one is to use our own process. 06:34:01 since katomo mentioned the review as part of process, i think git is the way to go 06:34:04 for the time being 06:34:32 and like ianychoi mentioned, we can't export yet from Zanata. 06:34:40 if we need glossary definition review, we do need to create the process by ourselves. 06:35:25 yeah, then we can't use Zanata for the glossary management. Because they can add/edit glossary without review 06:35:54 I have an idea. I will change the glossary file from pot to a rst, with some format. And the rst file will contain both the glossary, and the context definition, just as Akihiro requested in his email. 06:36:55 And then, I create a script to extract the glossary from the rst and change into a pot file. In that situation, the i18n.pot is generated , same as other projects. 06:37:08 so we could follow the other projects process to upload, translate and download. 06:37:37 but how often you run the extraction? 06:37:38 sounds good 06:37:43 +1 06:38:06 The only thing that cannot be manually done, is that, I should covert the pot/po files into cvs file and upload to Zanata. 06:38:29 s/cannot/can 06:38:47 no, still wrong. 06:39:00 why dont you extract from rst and straight into csv? 06:39:04 The only thing that cannot be automatic done, is that, I should covert the pot/po files into cvs file and upload to Zanata. 06:39:50 does Zanata support csv translation ? 06:39:56 yes 06:40:10 I think Jenkins or Zuul would support to convert automatically after merge (some guys would make a kind of scripts..) 06:40:22 http://docs.zanata.org/en/release/user-guide/glossary/upload-glossaries/ 06:40:26 po and CSV files 06:40:53 so po files are supported as a kind of glossary format. 06:41:17 That's good. 06:41:33 So I don't need to convert to csv. I just use po files. 06:41:46 yeah.. if thats the format you wish to use 06:41:48 csv doesn't seem to have context... 06:41:57 Yes, katomo 06:42:00 agree. Then let's use just po files 06:42:07 aeng: how is Zanata support context ? 06:42:13 katomo, we support pos and description in CSV 06:42:20 i think po file with translator help is preferable. 06:42:38 I agree with katomo 06:42:40 If we put a context description is a pot, will it be shown in the translator editor ? 06:42:43 aeng: great 06:42:45 for po files, we uses the po comments as context 06:43:00 will the po comments be shown in the translation editor ? 06:43:04 Daisy, yes 06:43:24 ok. That solves our problems. 06:43:29 hm... "description column" at data rows 06:43:35 Daisy, sorry, need to double check on that 06:43:51 ok. 06:44:19 I'm much clear now. 06:44:24 Thank you guys. 06:44:36 let's move to open discussions. 06:44:40 #topic Open discussion 06:44:48 Any topics to discuss here ? 06:45:06 stackalytics ? 06:45:53 Daisy, just confirmed, we dont show po's comment, but we show pot's comment in editor 06:46:06 ok. 06:46:29 Daisy: do you know the current status about stackalytics? 06:46:35 katomo, stackalytics, I'm working on the contributors list api and statistic for review 06:46:48 katomo: sorry, katomo, not much. 06:46:49 aeng: thanks 06:47:01 but not sure how much is done in openstack space 06:47:04 aeng is helping us on the Zanata API. 06:47:20 I didn't hear from Ilya recently. I will follow up with him. 06:47:20 think they might still be waiting on the Zanata api first before can proceed 06:47:44 then Transifex 06:48:04 I have handled all the requests. 06:48:26 nice work, Daisy 06:48:27 I want to do a back up before we completly delete it. 06:48:51 do you have any suggestions on how to do the back up ? I could download all the resources. 06:49:13 pull all the resources using their client 06:49:16 In my mind, I could use github to store all these resources. 06:49:38 For transifex, I have found that two docs pages mention Transifex on the bottom. 06:49:38 agree on github 06:49:41 #link http://docs.openstack.org/fr/ 06:49:46 agree 06:49:48 #link http://docs.openstack.org/pt_BR/ 06:50:00 Sorry for the first one 06:50:05 ok. somebody should change it, Thank you, ianychoi. 06:50:13 But I don't know French.. :) 06:50:16 good eye on that 06:50:30 okay, I will fix 06:50:31 #link http://docs.openstack.org/de/ 06:50:46 German also 06:50:54 should visit all the language for that page 06:51:48 Fortunatelly, there are Frence and German at docs core. 06:51:50 Any other questions ? 06:52:03 stats? 06:52:12 stats ? 06:52:19 katomo, thanks for caring that :) 06:52:24 Transifex activity itself exists on Transifex 06:52:40 no need anymore? 06:52:57 I didn't understand, katomo 06:52:57 are we using those stats? 06:53:09 you mean, the statistic data ? 06:53:16 Transifex is currently disabled.. isn't it? 06:53:19 Daisy: yes 06:53:42 aeng: we use it for ATC 06:53:52 There is no translations since October 06:53:59 a very few translations in Sep. 06:54:14 very few translations in September. 06:54:20 so the stats might be outdated already. 06:54:24 I think for next ATC, we could use Zanata data. 06:54:31 How do you think of that, katomo ? 06:54:59 yeah, we got api for translators statistics 06:55:01 ATC is one year 06:55:40 so pulling the stats @ december 31? 06:55:41 at least one activity for latest two releases.. 06:55:54 each one activity 06:56:28 but, it may be not so important 06:56:40 So one option is we keep Transifex till next September. The other one is that we export data and save it somewhere. 06:56:53 for Mitaka, +1 for Liberty and +1 for Mitaka development... strictly 06:56:56 not sure if transifex can export stats 06:57:03 I need to check if I could export all the information. 06:57:22 yeah, but if can't, then keep it until next sept 06:57:41 I think after next April, stats would be considered for Oct 2015 to April 2015, and Apr 2015-Oct 2015. 06:58:26 so its always april-oct stats? 06:58:28 ianychoi: i think so 06:58:30 katomo: Transifex could easily query the statistic data, from a beginning data to an end data. I think exporting into an EXCEL file might lose some information. 06:58:50 aeng: the key point is OpenStack release cycle 06:59:02 ah, gotcha 06:59:10 Daisy: great 06:59:22 it's time... 06:59:28 Yep 06:59:37 Then nothing more from me 06:59:56 query, save, and "delete all". 06:59:56 so ianychoi and katomo : according to the release cycle, when do we not need Tansfiex stats data ? 07:00:10 after next May 07:00:16 ok. Thank you. 07:00:20 after Mitaka release 07:00:21 :) 07:00:24 Then I prefer to keep it till next May. 07:00:30 yup. agree 07:00:34 +1 07:00:36 ok. 07:00:44 Thank you guys for all the important inputs. 07:00:47 you need the data after Kilo release activity 07:00:53 > Daisy 07:00:59 ok, got it. 07:01:18 I will close the meeting now. 07:01:24 alright, thank you guys. Thanks Daisy for chairing this 07:01:26 Thank you all for attending. 07:01:31 thanks 07:01:33 #endmeeting