linux-kernel - Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEjAshrMqZ654SbuXNuQrJV-fwq42wHe3sMpNrnMbT0gSzDPYw@mail.gmail.com>
Date:	Wed, 13 Apr 2016 17:11:24 +0900
From:	SeongJae Park <sj38.park@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	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 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.

Thanks,
SeongJae Park

>
> Thanks,
>
>         Ingo