08:01:43 #startmeeting OpenStack I18n 08:01:44 Meeting started Thu May 1 08:01:43 2014 UTC and is due to finish in 60 minutes. The chair is Daisy_. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:01:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:01:48 The meeting name has been set to 'openstack_i18n' 08:01:56 Good morning and good afternoon, everyone. 08:02:10 good afternoon 08:02:12 Hi :) 08:02:26 Hi, good morning everyone :-) 08:02:29 We will have I18n meeting now. 08:02:40 Hi, ygbo 08:02:46 Welcome to join. 08:03:19 #topic Whether to including the final : with strings 08:03:34 http://lists.openstack.org/pipermail/openstack-i18n/2014-April/000573.html 08:03:51 I guess, all of you have understood the problem. 08:04:11 In my mind, the question can be changed to "whether to keep punctuation in translatable strings". 08:04:13 The punctuation could include: colon, comma, full stop mark, and space. 08:04:24 I don't know if I'm right. Let me know your thoughts. 08:05:08 If including the punctuation is necessary for a team to produce high quality translations, I think we should keep it. Otherwise the translations just look wrong in some languages 08:05:21 Trailing/leading spaces in English strings IMHO have to go, the rest can stay - I came to the conclusions that else it could pose problems with right to left languages 08:05:44 Articles like http://blog.transifex.com/post/49857043763/painless-software-localization (point 6) recommend keeping it, in particular because of French 08:06:06 I agree, jpich, to keep them. My point is to include punctuation. In Chinese, punctuation should also be translated. In Chinese, we have different characters for English colon and Chinese colon. 08:06:27 I think, the question is space. 08:06:40 DeeJay1 is right, inside strings, translators will be able to handle them, but trailing ones when concanated will not be properly handled in all languages. 08:06:50 I agree with DeeJay1 re:spaces :) 08:07:12 Is space important ? Is it important to add spaces at the end of a string? 08:07:36 I don't think so. 08:07:59 Daisy_: "in english: we say this", "en fran�ais : on dit �a" <- different spacing 08:08:07 I thinks it's just bad design, if spaces have to be used for a visual indent 08:08:10 Space is also a punctuation. It can separate words, right? 08:08:26 ygbo: I think we're talking about strings like "Image details" vs "Image details " 08:08:37 Right. 08:08:43 Daisy_: right 08:08:53 yes, but trailing spaces are only in cases like "My string " + "other string" - which is bad code 08:08:59 If codes like "Image details " + varaibleS 08:09:21 jpich: rigth too :-) 08:09:32 this should be "Image details %(variable)s" % variable 08:09:35 If a code like "Image details "+, I think, space is necessary. 08:09:56 All right, DeeJay1 08:10:11 So this is why the variable should be "in" the string 08:10:13 yup, but in such cases the translator doesn't even know that something is coming after the string 08:10:29 We are not able to think out a scenario that space is necessary, right? Think carefully. 08:10:48 * epico also thinks it is bad code. 08:11:20 because if the variable is "in" the string, the translator can move it around, words are not at the same place in all languages, and concatenation leeds to words at the wrong place in some languages. 08:11:42 I think there are bast practices for coding, and we should document them. 08:12:02 the code like "My string " + "other string" usually is avoid in gettext. 08:12:06 Agreed, concatenation is bad and we need to start fixing this in Horizon. Dough Fish and ygbo raised a few points about this on the mailing list, in answer to today's meeting agenda 08:12:10 ygbo: what's your point? Keep space or not? 08:12:53 ygbo, I got your point. 08:13:33 Daisy_: we should not concatenate strings and use variables instead, and we would not need trailing spaces anymore. 08:14:12 Daisy_: translators might need to move variables around, while they can not change the order of concatenation. 08:14:30 let me summarize 08:14:47 the punctuation is necessary for a team to produce high quality translations, we should keep it, except spaces. 08:15:24 Developers should avoid to concatenate strings and use variables instead, in order to avoid a string ending with spaces. 08:15:46 correct? 08:15:51 +1 08:15:58 +1 08:16:01 +1 08:16:01 Sounds good to me. 08:16:02 +1 08:16:05 Er, +1 08:16:11 :) 08:16:14 :) 08:16:18 +1 08:16:45 +1 08:17:04 Daisy_, Since there is a character Visarga (ः) in Hindi similar to colon, so to avoid the problem translator sometime use long dash instead of the colon. If we need want to use colon, we should put one space before the colon. 08:17:14 Thanks. So I will put it as a comments to https://bugs.launchpad.net/horizon/+bug/1296075 and https://review.openstack.org/#/c/84342/. 08:17:16 Launchpad bug 1296075 in horizon "Needles duplication in strings" [Low,In progress] 08:17:27 Thanks, Daisy_ 08:17:39 Daisy_, Ref: http://svn.fedorahosted.org/svn/fuel/language/hi/style_guide/ 08:18:24 any comments to rajeshr 's point ? 08:18:46 rajeshr: wow, nice 08:19:08 Daisy_: nope, it boils down to "include colons" in original strings 08:19:25 * DeeJay1 is sorry for all the confusion this topic caused because of him 08:19:38 rajeshr: you hope developers to use "details :" other than "details:" 08:20:15 DeeJay1: Thanks to you we now have a clear understanding of the problem and a solution everybody agrees on :) 08:20:56 Daisy_: we should not use "details:" but "details: %(topic)s" 08:21:09 Daisy_, no, details: is fine, actually the above comment is for Hindi that if anybody want to use colon in Hindi better use the way suggested as it is simmilar to one char in Hindi 08:21:26 in English Source string should be as it is 08:21:37 ok. 08:21:49 so we are OK for the first topic now ? 08:22:40 let's move to next topic. 08:23:01 Ok 08:23:15 #topic whether to add context-maker for better translations 08:23:30 I think this one is harder. :) 08:23:36 Yep :-) 08:23:45 yep :) 08:24:05 ygbo: would you like to say something about it ? 08:24:06 the issue is that "we do not necessarely need contextual markers in a string like this one" <- 08:24:20 "here we need some" <- (too short) 08:25:38 some strings just have a single word , an example is "May" <- is it the month or the verbe granting permission? 08:25:59 I think there are also two aspects to the question: whether to do it for future strings (I think yes, and that this is the easy question), and what to do with existing strings as this may force retranslating them (though hopefully the translation memory would help?) 08:26:43 this is where fdot can say something about it 08:26:47 I am agree on the first part for adding context in new string. 08:27:07 But for the second part, i think we should not change anything 08:27:09 amotoki had introduced context-maker in Havana release, and it caused the translators have to retranslate them. 08:27:26 let's leave the strings already translated 08:27:48 translation memory can help. 08:28:18 yes but translating again and again is not a good idea 08:28:37 fdot, what if the some languages have wrong/awkward translations because of this? Maybe we can fix only the ones we know are a problem? (When translators report them?) 08:28:41 for communities they will just see the same strings to translate again 08:28:49 If users report bugs/issues to complain about the translation quality, and we have to separate 1 string into two strings in the original language, we have to add context, even we have to re-translate them. 08:28:49 We should use contextual markers on new strings, and on "string change", but we can't use them on all the existing ones because as fdot mentionned it, the whole work done by translators would be lost and have to be redone. 08:28:59 jpich agree but 08:29:06 jpich: agree. 08:29:10 it depends of languages ;) 08:29:38 IMHO every introduction of a contextual marker to an existing string should be followed by fixing (copying the existing strings) the po files by that developer and an email to i18n list 08:29:39 I don't think we can add a contextual marker just for one language though :) 08:29:41 in french we can have a strange for a word but the translation could be nice for the others language ;) 08:29:45 amotoki reported the bug because Japanese had the issue. 08:30:53 jpich: indeed, contextual markers have to be language agnostic, they have to put a context on where the words or part of sentence is used. 08:31:04 It seems ok to me to report a bug + fix it in the code if a language is broken because of the lack of contextual marker 08:31:11 so I think, if there is issues in any languages, we should fix it. 08:31:12 s/the words or/the words are/ 08:31:30 DeeJay1: The po files are updated automatically by Jenkins, I don't think the devs can do that manually 08:32:01 any thoughts about adding context to new strings? any rules? 08:32:02 I am confused, i think we should use msgctxt irrespective of language 08:32:40 maybe just use msgctxt when it has problems for some languages? 08:33:31 epico: the problem is we can not forward guess which language will be impacted, imho, new strings should have msgctxt. 08:33:39 I think that's it yes. Context markers for new strings, only add to existing strings if a language team reports a problem 08:33:51 I don't think so, the language is so diverse and leaving it for translator to decide will be bad in long run 08:34:19 By the way, this will require some documentation for developer education (probably from ygbo, you seem familiar with it?), so we can learn when to use them and how to make them useful 08:34:20 jpich: also add if a string changes. 08:34:27 epico, so better use context marker whenever we think of any confusion 08:34:28 I think msgctxt is needed when the translatable string appears more than once... 08:34:39 jpich: sure :-) 08:35:08 epico: exactly :-) 08:35:13 ygbo: Thanks! :) 08:35:21 if the string only happens in one place, we don't bother to add the context marker. 08:35:27 ygbo, :) 08:36:24 in other OSS project, msgctxt is used when needed, I think. 08:36:39 epico, that is okay, but if any confusion developer see they can put a localization note like thing 08:36:42 epico: well, if it's a new string, we better still add one, because no one knows if we will have the same string somewhere else in the future. however, we don't need it for long sentences where the context is aparent in the sentence itsself. 08:37:14 rajeshr, yeah :) 08:38:25 so let me summarize again. 08:38:31 Context markers for new strings, only add to existing strings if a language team reports a problem 08:38:42 If the developper knows a word can have different meanings (example "may"), there the context is necessary. 08:38:50 Or if you change an existing string, I think ygbo would like to add? 08:39:02 jpich: +1 :-) 08:39:23 ygbo to add some documentation for developer education. 08:39:29 ygbo, I think maybe we can get the times of strings used in the pot file. 08:39:58 the exact string only appear once in pot file. 08:40:08 Daisy_, yes 08:40:10 exact same string only appear once 08:40:32 but the places of things is listed in the comment, feel correct me if I am wrong about it. 08:40:35 What's the goal of the once-off string? I'm not sure this is very visible to developers by default 08:40:43 s/things/strings/ 08:40:49 with different context, it will appear differently 08:41:37 we can get the times from the comments in po file. 08:41:40 #: tables/actions.py:381 08:41:40 #: templates/horizon/common/_data_table_table_actions.html:13 08:41:40 #: templates/horizon/common/_workflow_step_update_members.html:11 08:41:40 #: templates/horizon/common/_workflow_step_update_members.html:17 08:41:43 like above... 08:41:53 msgid "Filter" 08:41:54 msgstr "" 08:41:54 when we generate pot, the exact same string will appear only once. it's by default. 08:42:11 Daisy_, the information is in the comment. 08:42:19 epico shows a good sample. 08:42:19 Yes. 08:42:29 "Filter" is used 4 times. 08:42:33 I don't think most developers builds the po files when making a change though, since that's handled automatically by Jenkins 08:42:44 and there can be many changes so it wouldn't be easily visible 08:42:57 I'm not sure the "exact string only once" rule would be easy to enforce 08:42:59 currently 08:43:22 * epico means to reduce msgctxt usage, just for needed cases. 08:43:44 sorry, I mean for future msgctxt usage. 08:44:06 exact same string means same strings, no differences at all, even punctuation is same. 08:44:27 Daisy_, yes 08:44:27 epico: coders see the context in the code, but most translators do not and do not necesserly understand the python code, this is more usefull for coders to know where to look for when a translators comes asking for help. 08:44:39 While generating pot files, these strings will be merged into 1 msgid, and appear once in a single pot file. 08:45:01 * ygbo is talking abouth the line in the po where the string is 08:45:11 ygbo, I mean the developer can read the pot file to decide not to use context marker for strings used only once. 08:45:47 s/not/whether or not/ 08:45:50 if these strings are with same meaning, I think there is no need to use context. 08:46:05 Daisy_, agreed. :) 08:46:20 Using context will add more strings into pot file. 08:46:32 yeah 08:46:35 epico: the issue is that the pot file is not generated by the developper. 08:46:42 epico: I think we'll need input from the translation team if things are missed, because most developers don't look at the po files 08:46:53 jpich, okay 08:47:12 but for one place string maybe we can avoid the msgctxt. 08:47:51 if these strings are with same meaning, I think there is no need to use context. +1 08:48:02 +1 08:48:14 I think we can have a discussion when ygbo finishes the training document for developers. 08:48:27 Daisy_, ther is fedora SIG: https://fedoraproject.org/wiki/SSCG 08:48:29 Sounds great :) 08:48:36 work with the prob of context 08:48:47 I believe in this document, there will be more details, e.g. whether to add context for one place string. 08:48:58 Daisy_, https://fedoraproject.org/w/uploads/b/bf/Guidelines_for_contextualization.pdf 08:49:10 Daisy_: sure 08:49:12 great, rajeshr. 08:49:19 we can use them as the references. 08:49:22 could we also document the pot file of times of strings used in the document? 08:49:29 cool 08:49:37 why we document them, epico? 08:49:48 Daisy_, one more on FUEL: http://svn.fedorahosted.org/svn/fuel/qa/fuel-context-in-technical-translation-concept-and-guidelines.pdf 08:49:49 rajeshr: Do I understand correctly that this is a team that focuses only on adding context markers?? 08:50:21 Daisy_, I think developer need to add the context marker before translations... 08:50:56 jpich, I know some contributor here in SIG but don;t know in detail, mailing list is also there 08:51:34 I don't know if developers know about it, epico. 08:51:44 Daisy_, a guide about how to add context markers for developers. 08:51:57 that's what ygbo is going to wrint. 08:51:58 rajeshr: Nice! That would really help if some people took on that role too to help with new strings :-) 08:52:08 Daisy_, great. :) 08:52:29 ;et 08:52:47 let's move on, and we will have the second discussion when ygbo is done. 08:53:02 #topic I18n related sessions in design summit 08:53:31 about log message id generation 08:53:40 http://lists.openstack.org/pipermail/openstack-dev/2014-April/031855.html 08:53:42 There is one session in infrastructure track to discuss translation tools. 08:54:01 Daisy_, jpich, guess you saw the discussion? 08:54:05 There is another session in cross-project track to discuss log standards, including I18n standards. 08:54:29 Are there any other sessions that I miss ? 08:55:14 I think there's some conflicts with Horizon sessions again but I will try to make some i18n sessions as I can 08:55:26 OK. 08:55:26 Thanks, jpich. 08:56:04 epico: Are you working on adding error message ids? 08:56:19 Who will attend Atlanta summit, besides jpich ? 08:57:06 Let's move to open discussion 08:57:07 jpich, I think both English logging and Translated logging can replace the error message id. 08:57:14 #topic Open discussion 08:57:47 the English log is fit for the developers. 08:58:06 translated log is fit for users. 08:58:36 so epico's point is that "no need to add message ID" 08:58:49 Daisy_, right. 08:59:37 I think, no need to add ID for all messages, but for error messages, maybe it is useful. In that point, it's not message ID, but error code. 09:00:01 Daisy_, yeah, any details? 09:00:10 not much details 09:00:15 we could discuss off line 09:00:41 okay 09:01:00 Any other things to talk? 09:01:12 If no, I will close the meeting. 09:01:55 My network keeps on re-connecting again and again. :( 09:02:11 OK. Thank you all for attending. 09:02:17 thanks 09:02:20 thank you everybody 09:02:27 Especially thanks for people who are on holidays. 09:02:31 thanks 09:02:35 :) 09:02:36 thank you all. 09:02:37 :) 09:02:40 #endmeeting