00:00:38 #startmeeting OpenStack I18n Meeting 00:00:39 Meeting started Thu Oct 17 00:00:38 2013 UTC and is due to finish in 60 minutes. The chair is Daisy. Information about MeetBot at http://wiki.debian.org/MeetBot. 00:00:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 00:00:42 The meeting name has been set to 'openstack_i18n_meeting' 00:00:51 Welcome to join ! 00:01:00 We haven't been met for a month. 00:01:13 But we keep contaction through email. 00:01:26 #topic Summary of Horizon translation 00:01:45 We did a wonderful job in Horizon translation. 00:01:53 We have 12 languages 100% translated. 00:01:59 That's a very good result. 00:02:14 Many thanks to these translation teams. 00:02:27 great! 00:02:32 The translations have been merged and will be shipped with Havana release. 00:02:58 I have a question. 00:03:16 How do you hope our translators being recoginzed? 00:03:51 I mean, how to recognize these translators? 00:03:56 Will the name appear somewhere in the release? 00:04:21 The name will be shipped with the po file, that's true. 00:04:34 But I don't know how many people will look into po files. 00:04:39 right 00:05:14 So maybe I can ask how developers being recoginzed, and our translators can be recongized in the same way. 00:05:25 First of all, we need to have a list of translators. 00:05:31 A name list of translators. 00:05:49 I don't know how easily we can get the name list from Transifex. 00:06:00 we have no stats, so it`s kind of hard to know who really works 00:06:14 correct, gabrielcw 00:06:30 We could make some statistics just like the code contributors do, but need Transifex support 00:06:36 Well but if one is involved, and we ask the coordinators, we can get the names then 00:06:55 the coordinators should know I guess 00:07:03 I think so too. 00:07:10 so action 00:07:31 #action Daisy to get the translators name list and get a way to recongize them 00:07:58 ok. we move to next topic 00:08:08 #topic TODO items for the next 00:08:23 Before starting, here is a question. 00:08:29 How can we track the items we plan to do? 00:08:36 Blueprint in Transifex? 00:08:47 is there such thing? 00:08:53 in transifex? 00:08:55 No, 00:09:00 sorry, in Launchpad. 00:09:09 oh, right ;) 00:09:27 https://launchpad.net/openstack-i18n 00:09:35 we have this project in launchpad. 00:09:52 so I think we can use the blue print in this project to track the things we want to do. 00:09:56 That's nice 00:10:13 +1 00:10:14 :) 00:10:21 agree 00:10:26 Thanks, ujuc and dylan 00:10:49 #info Action item 1: build up the translation infrastructure 00:11:18 I hope to have a good translation infrastructure to support our translators' work. 00:11:48 Including a well design UI, good integration with the development team and the infrastructure team, a well designed progress. 00:12:03 process, I mean, a good release process. 00:12:05 maybe we could track with the lanchpad bugs/tasks 00:12:28 *launchpad 00:12:33 That's an idea, gabrielcw 00:13:14 Now we are using Transifex. 00:13:34 yet I think some of you may know that Transifex closed its source. 00:14:00 Some requests come from OpenStack community and CI team to evaluate other translation tools. 00:14:08 Like pootle 00:14:45 Actually, after Horzion translation, I began to like Transfix now. 00:15:13 I think its good to use, but lacks of support 00:15:21 But if Transifex won't support statistics , we will not be able to choose it. 00:15:38 and we will not have the stats, only in the paid version 00:15:46 Right. 00:15:49 yeah, Daisy 00:16:06 The stats is very important for a open source community. 00:16:14 Right 00:16:33 That's the problem. 00:16:43 So let's start from the requirements to translation tools. 00:17:04 Our requirements to translation tools, and then we find out if there is suitalble tools support. 00:17:34 I hope to find somebody else to lead this discussion in our mailing list. 00:17:46 Who want to do that? 00:18:27 maybe someone who knows more the existing tools 00:18:28 if nobody, I can do. 00:18:40 who setup the pootle test server? 00:18:53 I think a guy from CI team. 00:19:03 I know only tx, so I won`t be of much help 00:19:13 hehe. ok. I can. 00:19:37 #action Daisy to start the discussion in mailing list about requirements to translation tools. 00:20:52 After translation tool is selected, we need the tool to integrate with openstack development infrastructure. 00:21:16 I mean, something like the automatic syncronization between git and transifex 00:21:43 that's important 00:21:44 Now there are automation scripts to push and pull the translations from Transifex to Github for some projects, not all. 00:21:55 I remember somebody has said that Horzion development team don't like the daily update, there is no automation scripts for Horzion. 00:22:08 So that Akihiro Motoki made several manually translation update in Horizon release. 00:22:39 so .. not translation tool.... 00:22:40 http://www.penflip.com/ 00:22:46 that ... 00:22:54 What is penflip? 00:23:03 git like doc 00:23:12 document tool. 00:23:20 github :);; 00:23:22 how can it help our translation? 00:24:17 git-like documentation tool? 00:24:25 yes .. 00:25:14 I'm not clear how it is helpful for us, ujuc ? sorry I cannot catch you. 00:25:36 :) 00:26:36 well 00:26:48 Continue my talk, I think we also need discussion about the syncronization process too. 00:27:08 yeb.. 00:27:20 I mean, when to update the translation resources? When to download the translations to github? 00:27:38 Another mail-list discussion 00:28:24 is there a way to do this nightly/periodically by jenkins? 00:28:35 I think, even the translation resources being updated daily at the beginning of a release, our translators won't keep an eye on the translation update and work on the transation from day to day. 00:28:52 I think this could be done weekly 00:29:40 gabrielcw: think of this way, when Icehouse starts, and the translation resources are updated weekly, will you work on the translation? 00:30:11 well, yes 00:30:25 as far as I can I do this 00:30:25 Even the translation resources may be updated and deleted? 00:30:34 I see 00:30:49 Because they are not stable... 00:30:50 I am going to jump in here for a sec. We currently push .pot updates to tx whenever code updates change .pot and pull from tx and propose that to gerrit once a day. Is that not working well? 00:31:07 maybe we should wait then for the mid of the development to start? 00:31:12 Thanks for jump in, clarkb. 00:31:18 we are discussing. 00:31:39 In Horizon release, we start the translation when the string is called frozen.. 00:32:14 Surely, there is no really "forzen", there are a few changes after string frozen. 00:32:54 but we start the work when there is no that so many changes frequently. 00:33:33 But like that we may not have enough time to do it depending on the project ? 00:34:13 I think we need to find a time point for translators to start the work, when most of the strings are to some kind of "stable". 00:34:23 I mean, it may change something, but won`t change entirely , I hope :) 00:34:26 yes 00:34:41 gabrielcw is correct. The time point is very important, because translators also need enough time to work on the translation too. 00:35:26 I don't know. It's hard to decide. 00:36:19 Daisy, Do strings change that much during the development period? 00:36:22 between string/feature freeze and release you have ~6 weeks, but the first release candidates come out before that 00:36:48 I don't know, vkmc 00:37:00 Developers may know. 00:37:07 just to sample, is there a way to retrieve a diff to check if there are tipically many strings that are removed completely? This is the worst case. I noticed that some strings that changed just had typos fixed, or improved 00:37:45 so if one starts early it won't be a waste if there isn't that much removed strings 00:37:54 Daisy, I don't have much experience, but usually I don't see so many changes with strings 00:37:56 clarkb: Horzion has 1700+ strings. If more components include, that will be a big number of strings. 00:38:13 6 weeks is not enough. 00:38:26 Daisy: yeah, especially with the release candidates coming out sooner 00:39:52 If I'm a developer, and when I'm developing a feature, I may change the strings several times while I'm developing. But when I commit to a code repository, I may change, but may not that frequently. 00:39:53 We should take the decision considering the translation effort we will need if we decide to perform all the translations at the end of the release cycle, and the effort we will need to do if some strings change or get removed 00:41:19 you are right, vkmc. If we can get the numbers of string change in each commit, it will be helpful. 00:41:37 I usually contribute to Horizon with code reviews and don't see many changes in strings... that's why I ask... but maybe in other projects strings are more unestable 00:43:05 time is up. I just want to bring the our eyes to the current upload/download process, and the translation work in a release cycle too. 00:43:18 we can discuss in the mail list. 00:43:27 ok 00:43:42 Ideally, we need a git-like tool records all string changes, even for deletion and new strings. 00:44:07 dylan: as Transifex said, all strings deleted will be saved in the translation memory of Transifex. 00:44:47 so these strings can still be found when it is in the recomend list. 00:45:33 Can we do version control in transifex? 00:45:41 for string changes 00:45:42 actually, I'm thinking if it is possible to use a git repository to contain only the translation resources, other than saving the translation resources in other projects. 00:45:51 no, no version control. 00:46:26 for example, we use a git repository to store only po files, po file from each project. 00:46:56 maybe there's s better way, but we could harvest the repos and thn gather in a new repo the translation files 00:47:17 certainly there's a better way :) but like that would be transparent for projects 00:47:21 and our daily work in Transifex will be saved in this git repository, but the syncronize between this git repo to other code base git repo is a certain period. 00:47:57 gabrielcw: I like the word: transparent. 00:48:16 that's a possible choice. 00:48:21 I was thinking about using jenkins for that 00:48:43 jenkins can help, I'm sure. 00:48:48 Akihiro could help answer if this is possible 00:49:10 let's move to next item. 00:49:18 Documentation translation - Operation guide 00:49:21 hehe. 00:49:27 Again, operation guide is the top priority. 00:49:33 Again, we need to have the first PoC of translated document publish website. 00:49:48 We have talked about operation guide for many times. 00:50:02 it's enourmous! 00:50:03 I think we need a time line to push things go on. 00:50:04 haha 00:50:38 That will hurt 00:50:53 I hope we can have a ja document web site before summit, so that I can demostrate that to people. 00:51:04 I will try to push this happen. 00:51:26 Next item: message translation. 00:51:50 Not horizon, but messages in Nova, glance, and something else. 00:51:50 Oslo team is working on the codes refactor of the translate messages. 00:52:00 I think we can raise the requirements to them on behalf of users and translators. 00:52:08 So firstly, I want to understand our opinion to the I18n policies of messages. 00:52:19 There are some questions, like: 00:52:25 Whether to translate log messages? 00:52:34 Whether to localize the REST API response messages? 00:52:40 Whether to translate command line output messages? 00:53:03 Do you have any other questions or concerns to the I18n polices of messages? 00:53:16 good points 00:53:18 We can get a list and send to mail list and ask for inputs. 00:53:42 about localization of dates? 00:53:50 We are from different country and we are the users. so we can decide the policy and ask developers to change their codes. :)) 00:54:00 date is a good point. 00:54:02 sounds good 00:54:06 Daisy, How technical words should be translated? Or... should those be translated at all? 00:54:35 what does "technical words" mean, vkmc? 00:54:46 i see some problems with that, because I was wondering if I translate the date string, if the datepicker of the code will have this option you know 00:55:07 the message says dd/mm/yy and the datepicker fills mm/dd/yy 00:55:09 gabrielcw: I don't know the technical details of date localization. 00:55:26 gabrielcw: I don't know how it is supported in Python framework. 00:55:31 there's some development effort needed to support this kind of thing 00:56:07 depends mostly of the UI I think, so it's JS 00:56:11 Daisy, For instance, "Router" or "VIP" (Virtual IP)... there are others more complex 00:56:22 understand, vkmc . 00:57:29 In my opinion, whether to translate technical words should be discussed within the language translation team and get a consensus. 00:57:55 Then the whole language translation team should follow the agreement. 00:58:00 That's enough. 00:58:01 yes 00:58:03 Daisy, Sometimes there is a risk that the translation generates confusion, most technical users are used to read them in English 00:58:04 Agree 00:58:07 that's good 00:58:21 agree 00:58:27 I know decision is hard to make, vkmc . :) 00:58:48 Yeah :) 00:58:50 Like when I translate VCPU, I asked Akihiro Motoki what does it mean, 00:59:08 haha 00:59:09 I asked Akihiro Motoki whether he translated it. 00:59:12 I think this is also the problem for all translation projects 00:59:22 i got into this also 00:59:26 there are some common questions, yes. 00:59:57 but I'm open if different language teams have different answers. 01:00:20 time is up. 01:00:26 It's yeah, and it's important that we create a dictionary of those words in each translation team and have it as a guide to keep consistency 01:00:48 I will discuss it with the Spanish team 01:01:03 It looks like we need a lot of discussion within our mail list. I will summarize these questions together and send to mail list. so please actively express your idea in the mail list. 01:01:08 'a dictionary of those words in each translation team', that is necessary I think 01:01:24 I agree, dylan. 01:01:33 That can be a requirement to our translation tool. 01:01:44 right 01:01:57 OK. Nice to talk with you 01:02:08 Looking forwad to continue the discussion by email. 01:02:17 Yay :) Thanks all 01:02:21 Nice talk 01:02:24 Thank you for joinning the meeting. 01:02:24 :) 01:02:31 #endmeeting