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

[SeongJae Park]

On Wed, Apr 13, 2016 at 9:49 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
>> >
>> > * Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>> >
>> >> From: SeongJae Park <sj38.park@xxxxxxxxx>
>> >>
>> >> 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@xxxxxxxxx>
>> >> Acked-by: David Howells <dhowells@xxxxxxxxxx>
>> >> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
>> >> Acked-by: Minchan Kim <minchan@xxxxxxxxxx>
>> >> ---
>> >>  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.

>
> 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.


Thanks,
SeongJae Park

>
>                                                         Thanx, Paul
>