Vincent, This is awesome. Thank you to you and everyone else in this project. This is just excellent! Zach Vincent Isambart wrote: > Hi everyone, > > Here they are, translations of chapter 3, 4 and 6 of the Ruby Hacking Guide! > We know the translation is far from being perfect, and we welcome any > correction on the text or diagrams of any chapter (even chapter 2). > Please send them as patches (attached to the mail, not just in the > body of the message) on the rhg-discussion mailing list > (http://rubyforge.org/mailman/listinfo/rhg-discussion). The patches > should be done against the text files in the SVN repository > (http://rubyforge.org/scm/?group_id=1387). > > We also introduced a new feature: previews. It means we put on the web > page chapters that have not be fully proofread and that may have > missing diagrams. They are labelled with a big 'PREVIEW' on it. So do > not hesitate to check our web page often to be able to read the > chapters before they are announced (and send us corrections!). For > example, the previews chapters released today were made available on > the web page more that one week ago. > > I may repeat myself but we still need people to help, especially > translators. If you can, even if it's only for one chapter, come help > us. Proofreaders are also welcome, the more they are, the better. > > I would like to especially thank the following people for making it possible: > - Clifford Caoile for translating chapter 3 > - Meinrad Recheis for making the diagrams > - Jim Driscoll for his proofreading > - and of course Minero Aoki for allowing us to translate his book. > > So if you want to read it, the official web page is still > http://rhg.rubyforge.org/ :). > > But wait! Today I also have a bonus: a quick translation of matz' > YAPC::Asia 2006 slides. The slide in Japanese are available here: > http://www.rubyist.net/~matz/slides/yapc2006/ > They are mainly about multilingualisation in Ruby 2. Many thanks to > matz for letting me post this translation and correcting my stupid > mistranslations. > > For those who have no idea what TRON or Mojikyo is, and what are the > problems of Unicode in Japan, you should check this: > http://www.jbrowse.com/text/unij.html > > So here comes the translation. It's fact from being perfect, but it's > still easier to understand than the Japanese version ;) > > -- beginning of the translation > YAPC::Asia 2006 > > Ruby on Perl(s) > > Yukihiro "Matz" Matsumoto > matz / ruby-lang.org > > Copyright (c) 2006 Yukihiro "Matz" Matsumoto, No rights reserved though. > -- > How was Ruby born? > * in a Lisp(ish) system > * I added object oriented capabilities > * and took in some Perl functions > -- > That's why > Perl is Ruby's big brother > -- > Or > Ruby's big sister > -- > Therefore > > Hello World is > print "hello world\n" > in Perl, Ruby or Python > -- > But in PHP it's > <?php echo "hello world"?> > quite different on this point > -- > Ruby and Perl are similar but > * Perl has everything > * Ruby's heart is object oriented > -- > Ruby and Perl are similar but > * Perl uses (most of the time) a functional word order > * Ruby uses a Japanese word order > -- > Functional word order > > print reverse(<ARGV>); > > prints the reversed ARGV. > -- > Japanese word order > > ARGF.readlines.reverse.display > > Take ARGF, > call readlines on it, > reverse readlines' result, > display reverse's result > (this is natural order in Japanese language) > -- > Ruby and Perl are similar but > - Larry is American (even if he studies the Japanese language) > - Matz is Japanese (even if he studies the English language) > -- > Ruby and Perl are similar but > * Perl is Unicode-centered > * Ruby is decentralized > -- > Ruby and Perl are similar but > * Perl uses UCS (Universal Character Set) > * Ruby is (will be) CSI (Character Set Independent) > -- > What are your complaints towards Unicode? > * it's thoroughly used, isn't it. > * resentment towards Han unification? > * inferiority complex of Japanese people? > -- > What are your complaints towards Unicode? > * no, no I do no have any complaints about Unicode > * in the domains where Unicode is adequate > -- > Then, why CSI? > > In most applications, UCS is enough thanks to Unicode. > However, there are also applications for which this is not the case. > -- > Fields for which Unicode is not enough > Big character sets > * Konjaku-Mojikyo (Japanese encoding which includes many more than Unicode) > * TRON code > * GB18030 > -- > Fields for which Unicode is not fitted > Legacy encodings > * conversion to UCS is useless > * big conversion tables > * round-trip problem > -- > If a language chooses the UCS system > * you cannot write non-UCS applications > * you can't handle text that can't be expressed with Unicode > -- > If a language chooses the CSI system > * CSI is a superset of UCS > * Unicode just has to be handled in CSI > -- > ... is what we can say but > * CSI is difficult > * can it really be implemented? > -- > That's where comes out Japan's traditional arts > > Adaptation for the Japanese language of applications > * Modification of English language applications to be able to process Japanese > -- > Adaptation for the Japanese language of applications > > * What engineers of long ago experienced for sure > - Emacs (NEmacs) > - Perl (JPerl) > - Bash > -- > Accumulation of know-how > > In Japan, the know-how of adaptation for the Japanese language > (multi-byte text processing) > has been accumulated. > -- > Accumulation of know-how > > in the first place, just for local use, > text using 3 encodings circulate > (4 if including UTF-8) > -- > Based on this know-how > * multibyte text encodings > * switching between encodings at the string level > * processing them at practical speed > is finished > -- > Available encodings > > euc_tw euc_jp iso8859_* utf-8 utf-32le > ascii euc_kr koi8 utf-16le utf-32be > big5 gb2312 sjis utf-16be > > ...and many others > If it's a stateless encodings, in principle it can be available. > -- > It means > For applications using only one encoding, code conversion is not needed > -- > Moreover > Applications wanting to handle multiple encodings can choose an > internal encoding (generally Unicode) that includes all others > -- > If you want to > * you can also handle multiple encodings without conversion, letting > characters as they are > * but this is difficult so I do not recommend it > -- > However, > only the basic part is done, > it's far from being ready for practical use > * code conversion > * guessing encoding > * etc. > -- > For the time being, today > I want to tell everyone: > * UCS is practical > * but not all-purpose > * CSI is not impossible > -- > The reason I'm saying that > They may add CSI in Perl6 as they had added > * Methods called by "." > * Continuations > from Ruby. > Basically, they hate losing. > -- > Thank you > -- end of the translation > > -- > Cheers, > Vincent "scritch" ISAMBART >