Messages in this thread | | | From | SeongJae Park <> | Date | Mon, 18 Apr 2016 18:31:26 +0900 | Subject | Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation |
| |
Well, looks like there is neither strong positive opinion nor strong negative opinion. So, I will post the patch again with the suggested workflow soon.
Thanks, SeongJae Park
On Sat, Apr 16, 2016 at 8:23 AM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote: > On Fri, Apr 15, 2016 at 07:17:17AM +0900, SeongJae Park wrote: >> 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. > > It does sound plausible to me, but given that I have never done any > similar translation projects, I cannot be very confident in my judgment > in this area... > > Thanx, Paul > >> 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 >> > >> >
| |