From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752697AbcDOXXa (ORCPT ); Fri, 15 Apr 2016 19:23:30 -0400 Received: from e19.ny.us.ibm.com ([129.33.205.209]:42868 "EHLO e19.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752090AbcDOXX0 (ORCPT ); Fri, 15 Apr 2016 19:23:26 -0400 X-IBM-Helo: d01dlp02.pok.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Fri, 15 Apr 2016 16:23:48 -0700 From: "Paul E. McKenney" To: SeongJae Park Cc: Ingo Molnar , Linus Torvalds , Andrew Morton , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , jiangshanlai@gmail.com, dipankar@in.ibm.com, Mathieu Desnoyers , josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, David Howells , Eric Dumazet , dvhart@linux.intel.com, =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , oleg@redhat.com, pranith kumar , Peter Zijlstra , "H. Peter Anvin" Subject: Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation Message-ID: <20160415232348.GB3687@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160412155228.GA27257@linux.vnet.ibm.com> <1460476375-27803-6-git-send-email-paulmck@linux.vnet.ibm.com> <20160413063805.GA14197@gmail.com> <20160413124953.GA3568@linux.vnet.ibm.com> <20160414152532.GE3755@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16041523-0057-0000-0000-0000040CD007 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 15, 2016 at 07:17:17AM +0900, SeongJae Park wrote: > On Fri, Apr 15, 2016 at 12:25 AM, Paul E. McKenney > wrote: > > On Thu, Apr 14, 2016 at 10:04:47AM +0900, SeongJae Park wrote: > >> On Wed, Apr 13, 2016 at 9:49 PM, Paul E. McKenney > >> wrote: > >> > On Wed, Apr 13, 2016 at 05:11:24PM +0900, SeongJae Park wrote: > >> >> On Wed, Apr 13, 2016 at 3:38 PM, Ingo Molnar wrote: > >> >> > > >> >> > * Paul E. McKenney wrote: > >> >> > > >> >> >> From: SeongJae Park > >> >> >> > >> >> >> This commit adds Korean version of memory-barriers.txt document. The > >> >> >> header is refered to HOWTO Korean version. > >> >> >> > >> >> >> Signed-off-by: SeongJae Park > >> >> >> Acked-by: David Howells > >> >> >> Signed-off-by: Paul E. McKenney > >> >> >> Acked-by: Minchan Kim > >> >> >> --- > >> >> >> Documentation/ko_KR/memory-barriers.txt | 3048 +++++++++++++++++++++++++++++++ > >> >> >> 1 file changed, 3048 insertions(+) > >> >> >> create mode 100644 Documentation/ko_KR/memory-barriers.txt > >> >> > > >> >> > So we seem to have little precedent for such big translations, so I'd like to have > >> >> > higher level buy-in first, before applying such changes. > >> >> > > >> >> > We do have some ko_KR material upstream already: > >> >> > > >> >> > triton:~/tip> ls -l Documentation/ko_KR/ > >> >> > total 52 > >> >> > -rw-rw-r-- 1 mingo mingo 35017 Apr 6 09:02 HOWTO > >> >> > -rw-rw-r-- 1 mingo mingo 12741 Apr 6 09:02 stable_api_nonsense.txt > >> >> > > >> >> > ... but that's introductory level material. > >> >> > > >> >> > Fundamentally English is the language of the Linux kernel, all in-code comments > >> >> > are in English. Furthermore, people who know English and don't speak Korean won't > >> >> > be able to fix the ko_KR side of the documentation - so most of the time there's > >> >> > going to be some lag. It's also going to be harder by maintainers to review > >> >> > patches to these files, especially if they don't speak Korean. > >> >> > >> >> Basically, I agree with your opinion. However, I still believe translations > >> >> would be worth to make them because of two reasons below: > >> >> > >> >> 1. Lots of kernel programmers are still suffering from English. > >> >> In this context, I am saying about not only hackers in this mailing list but > >> >> also programmers in wider Linux kernel ecosystem including students > >> >> and > >> >> employees in corporations that do not have interesting at pushing their works > >> >> to upstream. For them, translations can be very helpful and may attract them > >> >> to join upstream. > >> >> > >> >> 2. Quality of translation can be maintained via community. > >> >> Thanks to openness of Linux kernel community, translations will be maintained > >> >> via community people. If nobody updates a translation for long time, I think > >> >> it's death of the translation, not every translation. > >> >> Also, giving caution to the maintainer of each translation for frequent update > >> >> and quality of patches may help the problem. > >> >> > >> >> The help, attraction for still suffering programmers and maintenance quality of > >> >> translations could be little or nearly nothing, especially for documents that > >> >> are not introductory level. Despite of the possibility, I believe the > >> >> opportunity cannot be ignored. > >> >> > >> >> Also, for defense of this specific translation, I think every kernel programmer > >> >> must read memory-barriers.txt at once. Because the nature of parallel > >> >> programming is hard to understand for first time, it should be read widely and > >> >> easy to read. I think that's why this translation is necessary especially. > >> > > >> > One approach in the meantime would be to maintain the Korean version out > >> > of tree. One way to make this more effective would be to get together > >> > with other non-Korean non-English people and work out a common repository > >> > and workflow for translations of the more complex pieces of documentation. > >> > A long-term out-of-tree demonstration that translation would work well > >> > and would keep up with mainline might help build confidence in the > >> > practicality of this approach. > >> > >> I think the approach would be reasonable. In actual, I also maintaining my > >> github public repository for the patch. Only one part that arguable is _how_ > >> to demonstrate and prove it, in my think. Follow update for one or two month? > >> Get one or two Signed-off-by from the language speaker? I'm not sure about > >> that though. > > > > Excellent questions, and I believe that trying it out will be part of > > learning the answer. > > Good point. How about this workflow? > > 1. Translation contributor should maintain his (public) tree for the > translation work. > 2. After the translation has finished and updated, report the result in patch > format to the mailinglist. > 2-1. The report should contain information about the original working tree and > information about guarantee of its fast update and quality to move hearts > of original documentation maintainers. > 3. If it didn't moved the hearts, maintain the tree continuously for some > period and goto step 2. > > I think the workflow is almost same with the repeatedly updated and > periodically posted patchsets that including version difference information. > Only one difference is that it should explain itself about its translation > quality and future update. Because the workflow has already proved to work > well, I believe my proposal will work well, too. > > Once a translation following the workflow has merged, it can be a start of the > precedents that Ingo said and will help future translators and maintainers. It does sound plausible to me, but given that I have never done any similar translation projects, I cannot be very confident in my judgment in this area... Thanx, Paul > Thanks, > SeongJae Park > > > > >> > I do like the idea of translations -- that is after all why I queued > >> > your patch -- but to Ingo's point, in my experience, there are a lot > >> > more people who start translations than finish them. We currently do > >> > not have a good way to tell which translations are no longer keeping up > >> > and thus need to be pruned, and we would need one. For the introductory > >> > documents, a large number of native speakers of the language in question > >> > could help out. For the more difficult documents, the pool of potential > >> > contributors can be quite small. > >> > > >> > To see this, think about how you would judge a translation of > >> > memory-barriers.txt into (say) Malayalam. Then expand that to include > >> > (say) Telegu, Kannada, Orya, Assamese, Marathi, Konkani, Gujarati, > >> > Urdu, Koshur, Dogri, Ladakhi, Manipuri, Garo, Mizo, Odia, and Tripuri. > >> > Several of these languages have more speakers than does Korean, obscure > >> > though they may be. > >> > > >> > I suspect that this is one of the issues that Ingo is worried about. > >> > >> Yep, I totally agree about the point. Despite of that, I believe the small > >> chance cannot be ignored. For some non-English speaker, translation is really > >> helpful even though quality of the translation is bad. I think that's why lots > >> of global corporations are trying to keep translation of their product and > >> website despite of its low quality. Also, in some point (many people may not > >> agree with this, but...), we can think appearance of voluntary translation > >> itself means community in the language are already grown up in some level. > >> > >> In short, adding translation of non-introductory documents could lost quality > >> but helps someone and scaling of Linux ecosystem. > >> > >> By the way, I want to make clear that this is just _my_ opinion and anybody > >> would disagree. And, when opinions are conflicting, I think decisioning is > >> maintainers' role and I will not make objection about the decision. > > > > Well, given that we haven't actually tried it yet, all we have are > > our various diverse opinions. Jon Corbet did sound supportive, and in > > his role as documentation maintainer, that should give you some basis > > for optimism. > > > > Thanx, Paul > > >