login
Search
Hi all, I am posting Documentation/HOWTO which is translated into Japanese at bottom of this email. This document had been reviewed by JF project which has long history to translate documents into Japanese. (not only kernel but also FAQs). For JF, please see : http://www.linux.or.jp/JF/index.html Please also note that the page is written in Japanese, but you can see a lot of results there. Actually, this is my first trial to post Japanese translated document and here are some points I decided ; - Character encoding is ISO-2022-JP, which is normally used for email using Japanese. - Added "Singed-off-by" line - Left the JF header strings which include translator/reviewer's name - Non-patch format, simple text I would be happy if I could get your comments and suggestions. Though I know there are several issues to merge it, I want to have discussions with you to accomplish it. This email comes from strong recommendation from Greg K-H when he came to Tokyo two weeks ago. Thanks >Greg ----- Below lines are Japanese Translation of "HOWTO" ----- Signed-off-by: Tsugikazu Shibata <tshibata@ab.jp.nec.com> --- ================================== これは、 linux-2.6.21/Documentation/HOWTO の和訳です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 翻訳日： 2007/06/04 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com> 校正者： 松倉さん <nbh--mats at nifty dot com> 小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp> 武井伸光さん、<takei at webmasters dot gr dot jp> かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp> 野口さん (Kenji Noguchi) <tokyo246 at gmail dot com> 河内さん (Takayoshi Kochi) <t-kochi at bq dot jp dot nec dot com> 岩本さん (iwamoto) <iwamoto.kn at ncos dot nec dot co dot jp> ================================== Linux カーネル開発のやり方 ------------------------------- これは上のトピック( Linux カーネル開発のやり方)の重要な事柄を網羅した ドキュメントです。ここには Linux カーネル開発者になるための方法と Linux ...
This is Japanese translation of "stable_api_nonsense.txt", which is based on the same motivation of Tsugikazu Shibata. ----------------------------------------------------------------- Below lines are Japanese Translation of "stable_api_nonsense.txt" ----------------------------------------------------------------- Signed-off-by: IKEDA, Munehiro <m-ikeda@ds.jp.nec.com> --- ================================== これは、 linux-2.6.19/Documentation/stable_api_nonsense.txt の和訳 です。 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ > 翻訳日 ： 2006/12/3 原著作者: Greg Kroah-Hartman < greg at kroah dot com > 翻訳者 ： 池田 宗広 < m-ikeda at ds dot jp dot nec dot com > 校正者 ： Masanori Kobayashi さん < zap03216 at nifty dot ne dot jp > Seiji Kaneko さん < skaneko at a2 dot mbn dot or dot jp > ================================== Linux カーネルのドライバインターフェース （あなたの質問すべてに対する回答とその他諸々） Greg Kroah-Hartman <greg at kroah dot com> この文書は、なぜ Linux ではバイナリカーネルインターフェースが定義 されていないのか、またはなぜ不変のカーネルインターフェースを持たな いのか、ということを説明するために書かれた。ここでの話題は「カーネ ル内部の」インターフェースについてであり、ユーザー空間とのインター フェースではないことを理解してほしい。カーネルとユーザー空間とのイ ンターフェースとはアプリケーションプログラムが使用するものであり、 つまりシステムコールのインターフェースがこれに当たる。これは今まで 長きに渡り、かつ今後も「まさしく」不変である。私は確か 0.9 か何か より前のカーネルを使ってビルドした古いプログラムを持っているが、そ れは最新の 2.6 カーネルでもきちんと動作する。ユーザー空間とのイン ターフェースは、ユーザーとアプリケーションプログラマが不変性を信頼 してよいものの一つである。 要旨 ---- あなたは不変のカーネルインターフェースが必要だと考えているかもしれ ないが、実際のところはそうではない。あなたは必要としているものが分 かっていない。あなたが必要としているものは安定して動作するドライバ であり、それはドライバがメインのカーネルツリーに含まれる場合のみ得 ることができる。ドライバがメインのカーネルツリーに含まれていると、 他にも多くの良いことがある。それは、Linux をより強固で、安定な、成 熟したオペレーティングシステムにすることができるということだ。これ こそ、そもそもあなたが Linux を使う理由のはずだ。 はじめに -------- カーネル内部のインターフェース変更を心配しなければならないドライバ を書きたいなどというのは、変わり者だけだ。この世界のほとんどの人は、 そのようなドライバがどんなインターフェースを使っているかなど知らな いし、そんなドライバのことなど全く気にもかけていない。 まず初めに、クローズソースとか、ソースコードの隠蔽とか、バイナリの みが配布される使い物にならない代物[訳注(1)]とか、実体はバイナリ コードでそれを読み込むためのラッパー部分のみソースコードが公開され ているとか、その他用語は何であれ GPL ...
Sweet! But could we have it in UTF-8? Jan -- -
Not speaking Japanese, I'm probably missing some fundamental translation issue, but the English word is "volatile", not "valatile". -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. -
This is a translation note for the "volatile" which is used as a double-meaning word in original. "valatile" is my mistake to spell, wrong spelling 3 times...sorry. -- IKEDA, Munehiro -
I think there's consensus that documents in the kernel source should Unfortunately I don't speak japanese so I can't say anything about the translation at all, but I do have some other comments/questions. If we start adding translated versions of documentation to the kernel source how should we organize the documents? Should each language get a sepperate directory in Documentation/ - like Documentation/JP/, Documentation/EN/, Documentation/DA/ etc? With multiple translated versions of the documentation in the tree, don't we run the risk that the translations will quickly become outdated since most people updating the documentation won't be able to update the translations? Since the common language of most kernel contributors is english I personally feel that we should stick to just that one language in the tree and then perhaps keep translations on a website somewhere. So the authoritative docs stay in the tree, in english, so that as many contributors as possible can read and update them. It would then be a seperate project to generate translations and keep them updated according to what's in the tree. Perhaps we could get the kernel.org people to create an official space for that and then place a pointer to that site in Documentation/ somewhere. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -
I'd prefer the 'standardized' "ja_JP", "en_US", "de_DE", "nb_NO", etc. What's more, the kernel tarball grows and grows :( Jan -- -
Oh really? Yes, that's the point. At least for Japanese, there is a great activity "JF" as Tsugikazu Shibata mentioned. It is a separate project from the tree, and it often happens that some documentations are outdated. If we could merge them, they could be kept up-to-date IMHO. But, on the other hand, it is fact that kernel tar ball would bloat. Your opinion above as "creating official space in kernel.org and putting pointer in Documentation" seems good for me. Hmm... -- IKEDA, Munehiro -
No, I think the translated files should be in the tree proper, we have the space :) thanks, greg k-h -
NO, it's easy. iconv -f ISO-2022-JP -t UTF-8 <infile >outfile We are usually using ISO-2022-JP for email exchange and if anyone would comment on my document, this is better I believe. For documentation purpose, I agree with UTF-8. Thanks, Tsugikazu Shibata -
well I can't! Not sure if this is a flaw in pine, but all I get is [hexcode][hexcode][hexcode] and a bit of 7bit throughout. EUC-JP and UTF-8 are no problem though. *shrug* Jan -- -
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
We once discussed about .po files for kconfig and back then the conclusion was not to keep them in the kernel tree. I advocated that they should stay out back then. But on the other hand I do not see it causing much troubles having scripts/kconfig/po/da.po etc araound. Any opinion about the .po files? Sam -
Like with translated doc, they might get out of date easily. Jan -- -
The difference here is that with .po files we have tools to report the actual translation status. And having the .po files included in the source makes it much easier to use the latest versions. The Linux Kernel Translation Project http://tlktp.sourceforge.net/ have nice statisitcs for the different translations. Italian is 100% followed by Hungarian with almost 70%. We have a number of dedicated people, so why not make the works available to more users by including it in the kernel. I trust the tlktp people enough that we will not see patches for the language with less than ~5% translated strings. I would assume that Japanese soon get higher btw - there is quite a number of people listed as translators. Sam -
Well, if for each document you translate, you record what revision you translated (git hash or kernel release), it's fairly easy to generate diffs and know what changes need to be translated. I don't think keeping the translations of Documentation/ in the kernel tree eases this significantly though. -- Mathematics is the supreme nostalgia of our time. -
From me, the same opinion as about any and all internationalized content in the tree -- please don't. All that stuff only serves to multiply the speed at which a fixed percentage of content obsoletes itself. When it's still new and shiny, sure, stuff will get translated but in no time at all it'll become a fragmented mess which nobody ever feels right about removing because that would be anti-social to all those poor non-english speaking kernel hackers out there. In current effect, English is the language of the linux kernel. Its messages are in English, most or all of the useful information available on it is in English, its developers communicate in (some semblance of) English... More importantly even than any current practical situation though it seems this should also be how people should try to keep things. I'm not a native English speaker myself but English serves well as a common language among all us non-native speakers. I really do not so much want to have to learn more languages well enough to be able to understand technical discussions about operating system kernels in them still. America is obviously historically (for a sufficiently short value of history) the main supplier/originator of computer software and as such, using English is often seen as something that needs to be fixed upon expansion but this is wrong. Please do not for a minute believe that internationalization is doing anyone a favour. I know all about constantly translating computer terminology back and forth when a non-computer savvy friend asks something in the context of his/her Dutch language copy of Windows. Internationalization is sometimes _neccessary_ (those same windows desktops) simply because the result needs to be used by people that you don't want to have to expect to be able to use English (because you'd limit your market) and things like adopting a character set that allows people to write down their names is obviously wonderful but generally ...
Stick a ";-)" on that, by the way... Rene. -
I agree. i18n efforts won't help one iota because people just have to know English in order to participate in l-k development. They should be able to read _and_ reply_ to lkml posts, and read and understnd code _and_ comments_. Those who cannot participate in development because they don't know English, won't get much help from some bits of semi-obsolete Documentation/* being available. Ok, they will read it, then what? How they are supposed to read the code? Write email? etc... There is only one practical solution: learn the language. It's not about *English* per se. It just happened so historically that CS has originated in English speaking countries. BTW, I learned it by reading sci-fi (Asimov's Foundation was the first thing), and then lkml. :) -- vda -
Kconfig is different since the target audience and the majority of users
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Well, hardly. The percentages quoted vary wildly with the point someone is trying to make but "user users" are expected to just use whatever their distribution provided them with meaning the Kconfig target audience is developers and "power users". Enough of the latter around certainly but I have no indication whatsoever that a significant number of them is lost in the water without Kconfig translations either. Internationalization is not very useful, has great potential to introduce even more chronically bit-rotting content and is finally counter-productive in maintaining a non-forking single community, at least in so far as it is today. One should spit on internationalization. Rene. -
That's a ridiculous statement. Non-native language abilities and technical competence have very little to do with each other. People have to understand the code and figure out what it is that they want to change. As long as this is done cleanly and the intent is obvious, language doesn't even factor in beyond the Signed-off-by tag. Explanation is necessary from time to time, but it really depends on the area in which someone is working. If it's a complicated and involved change, then of course it takes a bit more effort on both sides, but that doesn't It's arguable whether those that know English well derive any benefit from semi-obsolete Documentation/* files either. One could speculate that not being able to read semi-obsolete documentation and being forced to read the code is actually more productive ;-) Besides, Kconfig localization is more for the end users than the developers anyways. I certainly don't see any problem with this, the more people eyeballing the documentation, the easier it is to find out areas I suggest you step outside of your box and spend more time working with people who speak little to none of the languages you understand. -
Point me to one person who doesn't know English at all and who has successfully participated in l-k devel. I'm not saying that non-English should banned or something. In Kconfig it can even make sense. A section on kernel.org where people can put translations is also a good idea. I can still think that it is almost useless activity, but who knows, maybe I'm wrong. Just not Documentation/<lang>/* thing and no i18n of printks. -- vda -
There are entire architectures that have been merged and maintained by folks who speak little to no english, for example. I'll let you figure out which ones. Many drivers and such, too. Perhaps you've simply never noticed since these folks tend not to be terribly vocal. This is not to say that there aren't communication barriers, but things Documentation/* is in enough disarray as it is, I think it's worth having more people looking at it and verifying that things are up to date and accurate, regardless of what language they happen to be working in. Kconfig localization (is is that time of year already?) is another problem entirely, and one that doesn't have a lot of chance of being kept up to date. Documentation/* on the other hand isn't terribly prone to heavy modification, I'd wager most people would rather be lining up to voluntarily rewrite the floppy driver than even accidentally cd in to Documentation/. In any event, the rate of change is far lower, and people at least have a chance of keeping translations updated. Documentation is one area where we simply suck, the more people working on it, the better. -
That sounds nice maybe but it's actually simply false. Natural language abilities and computer language abilities are very much related. You also seem to ignore the other point that you don't _want_ to have significant groups of people go off in different directions and not communicate other than by a few selected interpreters. Here, as in most situations, communication is something to promote, not something you want to make easier to avoid. I see your linux-sh address which seems to point embedded-wise? Really need even better examples of significant groups of developers going off in different directions, not communicating and not doing Linux or themselves a And I suggest the first thing they learn about Linux is enough English. Many did. Rene. -
These days the configuration menus are not something that users need to read, they're more like a developer tool. IMO there's not much value in it, because the people who read it already know english most of the times. -
The majority of Kconfig users are _not_ kernel developers.
There are many different reasons why people compile their own kernel,
and "sysadmin who knows his hardware and the filesystems of his disks"
is really sufficient for compiling your own kernel.
Whether non-English Kconfig texts are important might be a question, but
if there are people doing the translation work there's no problem with
it.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Why not (if there are people willing to do the translation work).
The only thing I consider important is that this doesn't imply any kind
of string freeze at some time prior to a release (but .po updates
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I have no objection for them to be around in the tree, it might help out some users who want to build their own kernels, and allow the -stable kernels to catch up on the translations. So I would encourage their addition, if possible. thanks, greg 'not everyone speaks english' k-h -
Frankly i don't see the difference between this and the annual reoccurring "why can't the kernel messages be localized" discussion. (Which is a little overdue, but maybe this replaces it this time.) I could see the point in ONE "HOWTO" file per language to get people started, but everything else is a pointless exercise. A developer/bug-reporter has to be able to express him-/herself in English and understand English, otherwise you can not accomplish very much. All the points of the localized-messages discussion: - You have to have a common language, otherwise you can't communicate. - The translation will per definition be out of sync - Translations tend to introduce (translation-)errors - ... also apply here. A little anecdote: Very Long ago (last millennium i think) SuSE defaulted to a german translated kernel for one release of their distribution. (And optionally for a few more) But even though i'm german i couldn't understand a single word. And here is the FAQ-Entry about the annually reoccurring discussion: http://www.tux.org/lkml/#s9-16 Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -
Yes, but this file, and the stable-api-nonsense.txt files are there to help people understand both the kernel's philosophy, as well as encourage them to help contribute. That is totally different from internationalizing the internal kernel messages (which, btw, some people are working on...) That I would not agree to as it's just too hard to keep up with and would be pointless in a way. So I really do want to see a translated copy of the HOWTO, stable-api-nonsense.txt, and possibly a few other files in the main kernel tree (SubmittingPatches, CodingStyle, and SubmittingDrivers might all be good canidates for this.) These files change relativly infrequently (the HOWTO file has had only 7 changes in 1 and 1/2 years, and they were very minor ones) and should be easy for the translators to keep up with. So, Tsugikazu, care to resend this file as a patch that I can apply to the Documentation directory of the kernel tree? I think it would be good to have there. thanks, greg k-h -
This was the part that i understood wrong. I thought the point was a translation of Documentation/*. A concur that translating this small set of files could be helpful. -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. -
I'd rather have a single file, marked "Japanese" (in Japanese), that had pointers to current translations. These will always be at least as current as whatever we have in the tree, if not more so. Especially when someone is trying to figure out how to work based on the year-old kernel their embedded vendor gave them. Further, it might be good for someone to be the "Japanese maintainer". This person's job would be to accept patches from non-English-speaking contributors, translate their commit messages and comments, then forward them to the appropriate places (Andrew, subsystem maintainers, LKML, etc.). They should also distill and translate feedback. -- Mathematics is the supreme nostalgia of our time. -
Knowing whether a translation is current or not would be useful ... perhaps the translated files could include the GIT blob SHA1 of the version they were translated from (and some human readable version string too :-) This would allow someone reading the documentation to know whether is really was current. If it isn't, it provides an easy path to see what changed in the source document since the translation was made. This same diff should lighten the load for people maintaining the translation. -Tony -
Well, actually, if you're going that route then extend GIT to have support for "related" files. Essentially you should be able to add metadata to a git tree which says: "files $SHA1-$PATH1, $SHA2-$PATH2, [...], are related". Then there would be a "git list-related" command with a "--mismatch" option which would list paths for which $SHA1 doesn't correspond to $PATH1 or $SHA2 doesn't correspond to $PATH2, etc. Some clever updating of related-status during commit/ clone/pull/etc could store information in the index about whether or not any given file is up-to-date with respect to its co-related files. For translations, when the English version of a document is updated it will automatically result in a "mismatch", allowing translators to do a simple git-diff and see what happened. Likewise, if the Japanese document is updated without changing the relationship then it might mean that somebody should see what changed and update the English version as well. If you determine that the change was irrelevant for the other language (spelling/grammar fixes, etc), then you just update the relationship and commit that change. It would probably be pretty trivial to implement a prototype using a '.gitrelated' file in the root of the git tree, although better integration with the index would really speed handling with lots of related files; instead of linear searching just iterate over the prepared-during-checkout "out-of-date" list. Cheers, Kyle Moffett -
Here is a patch of Japanese translated HOWTO. Thank you very much for lots of comment and suggestions.>all Bellow is what I have done: - Added Hiroyuki's comment with my own modifications as top notes. - Character encoding is UTF-8 - The file is put in Documentation/ja_JP - The patch is attached, not inlined because of MUA will sometimes force change the character encoding. Sorry. I think We may need to discuss with JF team about much better JF headers (written in Japanese) later. Thanks, Tsugikazu Shibata
And next, this is a patch-form Japanese translation of stable_api_nonsense.txt. Current temporary state is same as Tsugikazu Shibata's made. My former post was translation of 2.6.19 but this is of 2.6.22-rc4. I modified translation along with the change at 2.6.20, which is the latest version. (And corrected typo of "volatile". Thanks Alistair!) -- IKEDA, Munehiro
Definitely. Ha ha ha. Well, I re-made the patch and post instead of Tsugikazu Shibata. The containt is perfectly same as the former patch except for its encoding which is now truely UTF-8. (Actually, I fixed one broken line for only patching problem) Thanks Junio for the pointing out and the good tool. ;-) -- IKEDA, Munehiro
Following up on this thread (and various OLS hall conversations). I'm interested in linking to documentation translations from http://kernel.org/doc, and it seems to me that the best thing I can do for Japanese is just link to http://www.linux.or.jp/JF/index.html and let them handle the Japanese translations. For one thing, the documents discussed in this thread are already up there, and unlike me they can _read_ them and see if they're out of date or not. Just FYI. Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. -
But what is the point of having them in tree? - regular review process does not work for them. - regular release process does not work for them; translations want release few days after -stable is released. - kernel contributors will _not_ be able to fix them when they change the original. Plus, I'm not even sure if we have enough space. There are lots of languages. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
Wider exposure. It will greatly increase the "google-juice" of it and "space"? Since when are we running out of space? The kernel is "only" growing at 10% a year and is a mere 8.1 million lines or so. We have plenty of space on the mirrors to take up :) thanks, greg k-h -
On mirrors, maybe. But I have 9+ copies on local notebook, and that beast is out of space all the time :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
This is a great idea, thanks. What I'm not clear on is where this is intended to go? The below isn't a patch, so if it's intended to live on a website rather than in the kernel tarball, great. We probably want a link from the in-kernel HOWTO to that website. If it is intended to live in the kernel tarball, I'm not sure that's a good idea. There are a number of languages we could consider translating these and other documents into. -- Mathematics is the supreme nostalgia of our time. -
Hi, thank you for your work. I was impressed. BTW, how about adding following lines (both in Japanese and English) ? == This is translated "HOWTO" documentation. Original "HOWTO" is maintaind by Greg Kroah-Hartman <greg@kroah.com> and linux kernal mailing list. And this one is maintained by Tsugikazu Shibata <tsugikazu.shibata@jp.nec.com> and JF Projet <www.linux.or.jp/JF>. Because original HOWTO documentation itself is being updated day and night, this file may contain old sentences. Please contact JF project if you find problems in translation. It is guaranteed that this file is just a translation and doesn't contains any additional information, sentences. If you want to update "HOWTO", please update English version first. Don't fork from original if you update this file. Last Updated: 2007/06/04 Version: 2.6.21 == not worth writing ? -Kame On Sun, 10 Jun 2007 20:48:45 +0900 (JST) -
That sounds fine with me, and would be good to have. I also have no problem also CC:ing anyone who wants to translate this file with patches that happen to modify the originals. That way they can easily keep up with the minor number of changes that happen over time. thanks, greg k-h -
Hi, Shibata san's contribution was really great. I was impressed too. I think the important point is that Shibata san let the linux kernel community knows the translation work has been done and ask the feedback. I think this two way communication is very important. I think that some members of YLUG (Yokohama Linux Users Group) may help to review the translations. :-) Regards, Hiro -- Hiro Yoshioka mailto:hyoshiok at miraclelinux.com -
There are language problems, like s/contains/contain/. The author please try fixing them at the fist place instead of adding jobs to -- Qi Yong -
On Mon, 11 Jun 2007 18:21:30 +0800 Oh, sorry. I know I have language problem for years. My doc itself is of-no-use, I know. They will write their own by themselves. -Kame -
Please don't say that -- I perfectly understood what you were saying and as such it was of perfect use. There's a large number of non-native English speakers around the Linux kernel and noone is expected to write flawless English (that's including native speakers in fact). Getting a native speaker to clean up grammer and spelling is fine ofcourse as it's makes for a lower effort read for many others but please don't say that something which isn't flawlessly spelled is of no use. As long as the content is clear, it's of great use! Rene. -
On Mon, 11 Jun 2007 13:16:56 +0200 Thank you. But I know my grammar-check skill is not so good. I should make it better. I always thank all commenters who fix my sentences. Regards, -Kame -
It used to be customary at least on usenet to add "(sp?)" to a word you weren't certain about but it never worked for me. When I indicated I wanted to be acked/naked like that I really did but it was always just ignored. That in itself is enough indication of how deeply people care about spelling in technical content... Rene. -
