Message-ID: <20160413124953.GA3568@linux.vnet.ibm.com>
Date:	Wed, 13 Apr 2016 05:49:53 -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@...icios.com, josh@...htriplett.org,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	David Howells <dhowells@...hat.com>, edumazet@...gle.com,
	dvhart@...ux.intel.com, fweisbec@...il.com, oleg@...hat.com,
	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 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 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.

							Thanx, Paul

Powered by blists - more mailing lists