Message-ID: <20160418203326.GW3687@linux.vnet.ibm.com>
Date:	Mon, 18 Apr 2016 13:33:26 -0700
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	SeongJae Park <sj38.park@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	jiangshanlai@...il.com, dipankar@...ibm.com,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	josh@...htriplett.org, tglx@...utronix.de, peterz@...radead.org,
	rostedt@...dmis.org, David Howells <dhowells@...hat.com>,
	Eric Dumazet <edumazet@...gle.com>, dvhart@...ux.intel.com,
	Frédéric Weisbecker <fweisbec@...il.com>,
	oleg@...hat.com, pranith kumar <bobby.prani@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean
 translation

On Mon, Apr 18, 2016 at 06:31:26PM +0900, SeongJae Park wrote:
> Well, looks like there is neither strong positive opinion nor strong negative
> opinion.  So, I will post the patch again with the suggested workflow soon.

Makes sense to me!  Let's see how things look after a few months.

							Thanx, Paul

> Thanks,
> SeongJae Park
> 
> On Sat, Apr 16, 2016 at 8:23 AM, Paul E. McKenney
> <paulmck@...ux.vnet.ibm.com> wrote:
> > 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
> >> <paulmck@...ux.vnet.ibm.com> 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
> >> >> <paulmck@...ux.vnet.ibm.com> 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 <mingo@...nel.org> wrote:
> >> >> >> >
> >> >> >> > * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> >> >> >> >
> >> >> >> >> From: SeongJae Park <sj38.park@...il.com>
> >> >> >> >>
> >> >> >> >> This commit adds Korean version of memory-barriers.txt document.  The
> >> >> >> >> header is refered to HOWTO Korean version.
> >> >> >> >>
> >> >> >> >> Signed-off-by: SeongJae Park <sj38.park@...il.com>
> >> >> >> >> Acked-by: David Howells <dhowells@...hat.com>
> >> >> >> >> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> >> >> >> >> Acked-by: Minchan Kim <minchan@...nel.org>
> >> >> >> >> ---
> >> >> >> >>  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
> >> >
> >>
> >
> 

Powered by blists - more mailing lists