Messages in this thread | | | From | SeongJae Park <> | Date | Wed, 13 Apr 2016 17:11:24 +0900 | Subject | 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
| |