Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1376987 > unrolled thread

[PATCH memory-barriers.txt 0/7] Memory-model updates for 4.7

Back to article view | Back to linux.kernel

Contents

  [PATCH memory-barriers.txt 0/7] Memory-model updates for 4.7 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-12 18:00 +0200
    Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean  translation Ingo Molnar <mingo@kernel.org> - 2016-04-13 08:40 +0200
      Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation SeongJae Park <sj38.park@gmail.com> - 2016-04-13 10:20 +0200
        Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean  translation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-13 14:50 +0200
          Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean  translation Jonathan Corbet <corbet@lwn.net> - 2016-04-13 20:50 +0200
            Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean  translation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-13 21:10 +0200
          Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation SeongJae Park <sj38.park@gmail.com> - 2016-04-14 03:10 +0200
            Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean  translation "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-04-14 17:30 +0200
              Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation SeongJae Park <sj38.park@gmail.com> - 2016-04-15 00:20 +0200

#1376987 — [PATCH memory-barriers.txt 0/7] Memory-model updates for 4.7

Hello!

This series provides updates to everyone's favorite bedtime story,
Documentation/memory-barriers.txt:

1.	Clarify relationship of barrier() to control dependencies.

2.	Fix missed renaming: s/lock/acquire, courtesy of SeongJae Park.

3.	Add missed subsection in TOC, courtesy of SeongJae Park.

4.	Fix =/== typos, courtesy of SeongJae Park.

5.	Insert white spaces consistently, courtesy of SeongJae Park.

6.	Add Korean translation, courtesy of SeongJae Park.

7.	Mention smp_cond_acquire(), courtesy of Davidlohr Bueso.

							Thanx, Paul

------------------------------------------------------------------------

 ko_KR/memory-barriers.txt | 3048 ++++++++++++++++++++++++++++++++++++++++++++++
 memory-barriers.txt       |   78 -
 2 files changed, 3090 insertions(+), 36 deletions(-)

[toc] | [next] | [standalone]

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

* Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:

> From: SeongJae Park <sj38.park@gmail.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@gmail.com>
> Acked-by: David Howells <dhowells@redhat.com>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Acked-by: Minchan Kim <minchan@kernel.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.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

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

On Wed, Apr 13, 2016 at 3:38 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
>> From: SeongJae Park <sj38.park@gmail.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@gmail.com>
>> Acked-by: David Howells <dhowells@redhat.com>
>> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> Acked-by: Minchan Kim <minchan@kernel.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

[toc] | [prev] | [next] | [standalone]

#1377896 — 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@kernel.org> wrote:
> >
> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> >
> >> From: SeongJae Park <sj38.park@gmail.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@gmail.com>
> >> Acked-by: David Howells <dhowells@redhat.com>
> >> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> Acked-by: Minchan Kim <minchan@kernel.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

[toc] | [prev] | [next] | [standalone]

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

On Wed, 13 Apr 2016 05:49:53 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:

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

So I have to play the devil's advocate a bit here...  we don't currently
have a mechanism to tell us which files in Documentation/ in general are
not keeping up and needing to be pruned[0].  But we don't use that as a
reason to block documentation submissions in general.

It's a bit harder for a random passer-by to determine that a translation is
out of sync[1], but we do have a version control system that can help us to
see that, at least, somebody is occasionally updating things.  It's not a
complete black box.

I would argue in favor of including translations when somebody has taken
the time to create them.  They cost little and can be helpful for
developers who are struggling with both the kernel code and the English
language.

jon

[0] OK, a real devil's advocate would say that "ls" or even
    "echo Documentation/*" is sufficient.

[1] Though, perhaps, many or most developers can make just as much
    sense of a version of memory-barriers.txt in a language they don't
    understand as they can with the original. :)

[toc] | [prev] | [next] | [standalone]

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

On Wed, Apr 13, 2016 at 12:46:22PM -0600, Jonathan Corbet wrote:
> On Wed, 13 Apr 2016 05:49:53 -0700
> "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> 
> > 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. 
> 
> So I have to play the devil's advocate a bit here...  we don't currently
> have a mechanism to tell us which files in Documentation/ in general are
> not keeping up and needing to be pruned[0].  But we don't use that as a
> reason to block documentation submissions in general.
> 
> It's a bit harder for a random passer-by to determine that a translation is
> out of sync[1], but we do have a version control system that can help us to
> see that, at least, somebody is occasionally updating things.  It's not a
> complete black box.
> 
> I would argue in favor of including translations when somebody has taken
> the time to create them.  They cost little and can be helpful for
> developers who are struggling with both the kernel code and the English
> language.
> 
> jon
> 
> [0] OK, a real devil's advocate would say that "ls" or even
>     "echo Documentation/*" is sufficient.
> 
> [1] Though, perhaps, many or most developers can make just as much
>     sense of a version of memory-barriers.txt in a language they don't
>     understand as they can with the original. :)

Best laugh of the day!!!  ;-) ;-) ;-)

							Thanx, Paul

[toc] | [prev] | [next] | [standalone]

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

On Wed, Apr 13, 2016 at 9:49 PM, Paul E. McKenney
<paulmck@linux.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@kernel.org> wrote:
>> >
>> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>> >
>> >> From: SeongJae Park <sj38.park@gmail.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@gmail.com>
>> >> Acked-by: David Howells <dhowells@redhat.com>
>> >> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> >> Acked-by: Minchan Kim <minchan@kernel.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.

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

[toc] | [prev] | [next] | [standalone]

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

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@linux.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@kernel.org> wrote:
> >> >
> >> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
> >> >
> >> >> From: SeongJae Park <sj38.park@gmail.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@gmail.com>
> >> >> Acked-by: David Howells <dhowells@redhat.com>
> >> >> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> >> Acked-by: Minchan Kim <minchan@kernel.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.

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

[toc] | [prev] | [next] | [standalone]

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

On Fri, Apr 15, 2016 at 12:25 AM, Paul E. McKenney
<paulmck@linux.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@linux.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@kernel.org> wrote:
>> >> >
>> >> > * Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>> >> >
>> >> >> From: SeongJae Park <sj38.park@gmail.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@gmail.com>
>> >> >> Acked-by: David Howells <dhowells@redhat.com>
>> >> >> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> >> >> Acked-by: Minchan Kim <minchan@kernel.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.


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
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web