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

[SeongJae Park]

On Fri, Apr 15, 2016 at 12:25 AM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> 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@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.
>
> 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.


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
>