rust-lang-ja / the-rust-programming-language-ja Goto Github PK

現在 rust 1.6 と rust 1.9 の src/doc/book をベースに翻訳されていますが、それ以降のバージョンへの追従は行わない予定でしょうか。

特に lifetimes.md には 1.14 で例が追加されてかなり分かりやすくなっていますので、変更部分を追従すると読者にとってかなり助かると思います。
1.9 以降の内容を取り込む方針などあれば教えて頂ければ私から PR することも可能です。

参考
https://github.com/rust-lang/rust/blob/1.14.0/src/doc/book/lifetimes.md
fn skip_prefix(line: &str, prefix: &str) -> &str を使った例が追加されています。

CI 導入後の 初 PR で、1.6 と 1.9 の両方の book の修正をしたが、その修正内容が成果物としてアーカイブされた HTML に反映されていない。

修正内容：https://github.com/rust-lang-ja/the-rust-programming-language-ja/pull/154/files

生成された HTML（1.6 の ownership.html）：
https://circle-artifacts.com/gh/rust-lang-ja/the-rust-programming-language-ja/8/artifacts/0/tmp/circle-artifacts.3woFWmV/1.6/book/ownership.html

CI のログ を見ると、正しいコミットが checkout されている。

Checkout using CircleCI fork PR checkout user key: 72:d2:fd:18:4c:f5:15:b1:ab:47:44:65:9d:9b:08:0a00:11config
Warning: Permanently added 'github.com,192.30.252.123' (RSA) to the list of known hosts.

remote: Counting objects: 9, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 9 (delta 6), reused 5 (delta 2), pack-reused 0
Unpacking objects: 100% (9/9), done.
From github.com:rust-lang-ja/the-rust-programming-language-ja
   64f018c..b935f29  refs/pull/154/head -> origin/pull/154

また、make も特にエラーなく終了している。

更新されたファイルを make が検出してないのだろうか？　今のところ原因不明。

これから該当 PR をマージするので、そこで行われる master と gh-pages への git commit 内容を見ると、何かわかるかもしれない。

CONTRIBUTING.mdでは、

Markdownのマークアップ記法の前後は空白/空行を空けることを基本とするが、厳密でなくてもよい。

ということになっていますが、*などは前後に空白を入れないと、rustbookが認識してくれないようです。

http://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/effective-rust.html

https://github.com/blog/2309-introducing-topics

取り急ぎ、以下のトピックスを設定しました。

• rust
• document
• japanese

追加、変更、削除の要望がありましたら、当 issue へのコメントにてお知らせください。

既に公式ドキュメントは移行済み
https://github.com/azerupi/mdBook

• やや複雑になっている
• 差分翻訳の手引がない
• 機械翻訳の扱い
  CF Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話 - いくやの斬鉄日記

どの文書が翻訳済みでどの文書が未翻訳かを一覧する方法があるといいと思います。

• meta-issueを用意する（一般的なmeta-issueの例： dart-lang/sdk#23454）
• Wikiに表を用意する

http://qiita.com/tonkotsuboy_com/items/f98667b89228b98bc096?utm_campaign=popular_items&utm_medium=referral&utm_source=popular_items

現在トレイトのboundは「境界」と訳していますが、機能を考えると「制約・規約」といったほうが適切ではないでしょうか。トレイトがジェネリック型に「くっついている」ことのチェックという意味でのboundだと思います。

git subtreeが思ったよりつらい感じになってるのでやめたい。

See conversations at #271
@tatsuya6502 @chikoski

標準ライブラリのリファレンスへのリンクは基本的に相対パスで書かれているようなのですが、これは英語版のURLに置き換えればよいでしょうか。

変更前：[bool]: ../std/primitive.bool.html
変更後：[bool]: https://doc.rust-lang.org/std/primitive.bool.html

http://rust-lang-ja.github.io/the-rust-programming-language-ja/1.6/book/primitive-types.html#booleans

@chikoski さんが加わってくれるそうです。

いつの頃からか、PR に対する CI が走らなくなってしまっていた。Circle CI の設定を確認したところ、以下の設定がオフになっている。

Build forked pull requests
Run builds for pull requests from forks. CircleCI will automatically update the commit status shown on GitHub's pull request page

この設定は、以前はオンにしておいたと思うのだが、いつの間にかオフになっている？　もしかしたら、自分の記憶違いで、以前は、この設定自体がなかったのかもしれない。

Circle CI のヘルプによると、この設定をオンにする際は、セキュリティ上の問題がないか確認する必要があるようだ。

https://circleci.com/docs/fork-pr-builds/

Security Implications of running builds for pull requests from forks

Project settings on CircleCI often contain sensitive information which make running an unrestricted build in the context of the parent repository potentially dangerous. In general, any configuration which is made available to a build is accessible to anyone who can push code which triggers the build (eg., that person can include commands in circle.yml to echo the data to the terminal and see it on the build page.) So in this special case of running builds for fork PRs, we have to be careful.

There are 5 kinds of configuration data that we would normally use in a build which we suppress for builds triggered by pull requests from forks:
...

以前も確認したような気がするが...。念のため再度確認し、問題がなければ設定をオンにする。

中の人がgenerateを忘れてたらHTMLドキュメントに反映されない素敵仕様になってる

TODO

• rustbook の入手方法を調べる(現状よくわからないけどソースをコンパイルするとたまに使えるようになる)
• travis ci CircleCI をセットアップする
  • On PR でCI
  • On master mergeでCI
  • On master merge CIが通ったらgh-pagesブランチに自動push
    • そのためのmakeターゲットを用意

現状、バージョン毎にURLを切ってますが常に最新版を指すURLも欲しいなと思います。
その時点での最新版にシンボリックリンクを張るのが一番手っ取り早いかなと思っています。

名前はまだ考えてます

• latest
• current
• stable

「翻訳されたもののうち最新版」になるのでどの名前が適切か…。

共通の関数呼び出し構文と構文の索引において"inherent"が「継承（された）」と訳されていますが、これはトレイトを介さない実装を指す言葉なので継承（inherit）とは字面が似ているだけで別の概念です。

代わりにどういった訳語を当てるべきなのかは自明な問題ではないですが、よく使われているものとしては「固有」という訳があります（e.g. inherent impl: 固有実装、inherent method: 固有メソッド）。

メモ

The Rust Programming Language 日本語訳をe-bookにしてみる - Qiita
http://qiita.com/hmikisato/items/cc6700c09b28fdc7d9e1

目次の行間が大きいのでスクロール量が多く，一覧性があまりよくないように思います。

font-size: 14px に対して，line-height が 40px もあります。

https://github.com/rust-lang-ja/the-rust-programming-language-ja/blob/master/public/1.9/style/rustbook.css#L89

line-height は（単位なしの）1.5 くらいでちょうどいいのではないかと思いますが，いかがでしょうか。

こちらのリポジトリでCIが動作して成功した場合、PDF版を自動で更新したいと思っています（現在は私が適当なタイミングで手動により更新しています）。そのため、Circle CIの管理者に追加していただくか、すでにCircle CIに秘密鍵が登録されている場合はその公開鍵を教えていただきたいと思います。

@KeenS

https://github.com/rust-lang-ja/the-rust-programming-language-ja/blob/master/1.6/ja/book/getting-started.md

Tier 1 platforms can be thought of as "guaranteed to build and work".
1級のプラットフォームは「ビルド出来かつ動くことを保証する」ものと思えます。

Tier 2 platforms can be thought of as "guaranteed to build".
2級のプラットフォームは「ビルドを保証する」ものと思えます。

自分たちが設定した級について「思え」るというのはちょっと変な気がするので、「されています」くらいの方がよいように思います。

p59 スコープとシャドーイングの最初のサンプルコードにkというゴミが入っている。

https://rust-lang-ja.github.io/trpl-ja-pdf/a4.pdf

3/3に1.7が出るらしいですね。アップデートのこと考えないと。

Downloads · The Rust Programming Language
https://www.rust-lang.org/downloads.html

@dalance @KeenS @kw-udon @mandel59 @Nnwww @onobori @pocket7878 @ykomatsu @yohhoy

みなさま、

プログラミング言語 Rust (The Rust Programming Language) バージョン 1.6 の翻訳に参加いただき、ありがとうございました。おかげさまで、本日までに全ての章の翻訳を終えることができました ＊1。

• プログラミング言語 Rust 1.6

翻訳作業には、10名の方に参加いただきました ＊2。全部で70の章があり、原文の行数は合計で19,266行ありました ＊1。

翻訳した割合を元に、トップ５ランキングを出してみました。ただし、この数字は、翻訳したワード数ではなく、原文の行数を元にしてます。翻訳しないソースコード部分が含まれているなど、やや不正確な部分がありますのでご了承ください。

バージョン 1.6 翻訳ランキング　トップ５

敬称略。括弧内の数字は原文の全体の行数に対する、翻訳した割合 ＊3

第１位　　　　　@ykomatsu (20.5%)
第２位（２名）　@KeenS (16.6%)
　　　　　　　　@pocket7878 (16.6%)
第４位　　　　　@tatsuya6502 (14.0%)
第５位　　　　　@Nnwww (13.3%)

また、当プロジェクトをリードし、ほとんど全ての章の翻訳をレビューした KeenSさんにも、大きな拍手を贈りたいと思います。

今後ですが、バージョン 1.8 対応を予定しています。いまある 1.6 の翻訳に、1.8 の差分を加える形で進める予定です。みなさまのご参加をお待ちしております。

バージョン 1.6 翻訳作業の参加者 ＊2

敬称略。アルファベット順

• @dalance
• @KeenS
• @kw-udon
• @mandel59
• @Nnwww
• @onobori
• @pocket7878
• @tatsuya6502
• @ykomatsu
• @yohhoy

＊1: 1.7 で削除された「3.3. Rust Inside Other Languages」は未翻訳となっており、集計から除外しています。
＊2: この10名の他にも、誤字などの細かい修正のプルリクエストを送ってくださった人たちもいます。
＊3: プルリクエストを上げた方のお名前を元に集計しました。ただし、「7. 用語集」は、Nnwwwさんと、KeenSさんの２名で訳されましたので、行数を50%ずつ配分しています。

rust-by-example-jaでシンタックスハイライトが動作しない問題があったのですが、

**語と英語と比較した結果、独自ドメインを取得すれば解決するのではないかと考えました。

そこで、私の方で取得しようかと考えているのですが、せっかくなのでorganization全体のものを取ろうかと考えています。つまりrust-lang-jaでDNSを取得し、rust-lang-ja/rust-by-exampleとrust-lang-ja/the-rust-programming-languageで文書を表示という形です。

ご意見いただければ幸いです。

@KeenS @tatsuya6502

主にtools/にあるスクリプトのドキュメント化

TRPLの2ndエディションがアナウンスされた。 https://github.com/rust-lang/book
@tatsuya6502 さんと内々に話している限りでは 1stの最新版まで追い付いてから2ndに取り掛かる。

#7 #8 でも必要になる。

ブロックコードをコメントアウトするのがどうもgitbookと相性良くないようです。今のところブロックコードはコメントアウトせず削除することで対応しています。

幸い、コード中に出てくるコメントの分量はそこまで多くないので大丈夫ですが、いずれは対応を考える必要があります。

翻訳文中に、 全角の丸括弧 （） と半角の丸括弧() が混在しているので、どちらかに統一したほうが良いと思います。

個人的には半角推しですが、クォートのかわりに全角の鉤括弧「」を使っているのにあわせて、全角にするという考えもあるかもしれません。

Getting Started (和訳題: はじめる(1.9))についてです．

バージョン1.14.0のRust Bookの時点でrustup.shからrustup.rsの方式へ変更が行われました．
特に顕著なのがインストール方法であり，

• 1.14.0以前
  curl -sSf https://static.rust-lang.org/rustup.sh | sh
• 1.14.0以降
  curl https://sh.rustup.rs -sSf | sh

となった結果，初めて和訳ドキュメントを訪れた方がインストールに失敗する事態にあります．

特にGetting Startedは重要ですので，最新1.15.0版の更新PRを送りたいと考えています．ですが1.9更新分のレビューが目下進行中のため，どのタイミングでPRを送るのが好ましいか，そもそも1.9更新分のレビュー完了を待つべきか，私には判断が難しい所です．

従ってIssueにて報告させていただきます．

翻訳ありがとうございます。Rustの勉強をする上で助かりました。
こちらのRust by example
を和訳しようと考えています。せっかくなのでRust-lang-ja内に新しいリポジトリを作るのが良いと思うのですが、inviteしてもらうことは可能でしょうか。
ダメなら、
@tatsuya6502
さんに作っていただくか、私のリポジトリで勝手に行おうかと考えています。

Hi there! We're trying to translate the website into Japanese as well: rust-lang/prev.rust-lang.org#628

Would any of you be interested in helping review? Feel free to close this issue, as it's not a bug in the translation of the book, but I didn't know the best way to ask.

現在、第1版TRPLの各ページには、第2版への誘導リンクが表示されている。
https://doc.rust-jp.rs/the-rust-programming-language-ja/1.9/book/

注意: 第2版のドキュメントをご覧ください。 この第1版ドキュメントは古くなっており、最新情報が反映されていません。第2版のドキュメントが現在の Rust の最新のドキュメントです。

この誘導リンクを、まもなく公開する最新版（2018 Edition対応）へと変更する。

注意: 最新版のドキュメントをご覧ください。 この第1版ドキュメントは古くなっており、最新情報が反映されていません。リンク先のドキュメントが現在の Rust の最新のドキュメントです。

新しいリンク先は https://doc.rust-jp.rs/book-ja/

参考： #297

対訳表に入っているキーワードのenum、mut、structについては、

• 構文キーワードなどはそのままアルファベットを使う

という規則から一義的にアルファベットで表記することが決まるので、対訳表からは削除した方がよいように思います。

Circle CI Blog -- We’re Sunsetting CircleCI 1.0: August 31, 2018 is the Final Day for 1.0 Builds

TL;DR: After August 31, 2018, CircleCI 1.0 will no longer be available for Linux and macOS users. You can find guides for transitioning from 1.0 to 2.0 and a full timeline on planned changes here.

現在 Circle CI 1.0 使用しているが、2018年8月31日までに 2.0 へ移行する必要がある。（私は6月末くらいまであまり時間が取れなさそうなので、7月以降に作業します）

事前の確認不足で申し訳ないのですが、CI で生成して gh-pages へ push したページでは、Rust のコードブロックに「Run」ボタンが表示されていないことに気付きました（例）

調べたところ、book ディレクトリにある playpen.js の内容が、古いものに置き換わってしまったのが原因のようです。

• CI 導入以前の playpen.js - 正しい
• CI 導入以降の playpen.js - 正しくない。古い

CI では rustbook crate を使っていますが、そこの librustdoc/html/static/ に、rust リポジトリからコピーしたと思われる playpen.js があり、その内容が古いのが原因のようです。（CI 導入以前は rustbook crate は使わず、rust リポジトリからビルドした、本家の rustbook を使っていました）

rustbook crate の playpen.js を最新にするために、PR を出します。

#26 (comment) を独立した issue として管理。

変更の内容：
日本語翻訳ドキュメントでは、CSS（スタイルシート）により書式の置きかえを行い、<em>..</em> で囲まれた文字を、太字（<strong>..</strong> 相当）として表示されるようにする。

背景：
英語の原文では、単語もしくは文の強調に、マークアップの * と ** が使われている。前者は HTML の <em>..</em> に、後者は <strong>..</strong> に変換される。そして、一般的なウェブブラウザーの書式設定では、前者は 斜体、後者は 太字 として表示される。

しかし、日本語のフォントでは、斜体のデザインが用意されていないため、画面上で斜体が目立たず、本来の強調という目的はあまり果たせていない。一般的に、日本語の文書では、強調文字は太字に統一されている。

Rust の英語の文書を確認したところ、 * と ** は以下の１と２のような使い分けがされていることがわかった。日本語の文書では１も２も太字が使われるのが一般的なので、太字に統一して問題ないと思われる。

なお、CSS で書式の変更を行うので、翻訳文書のソースファイル中の * は、原文のまま変更する必要はない。また、このように書式を変更して、逆に読みづらくなったという意見が出るようなら、元に戻すことも検討する。

参考：Rust 英語の文書での使い分け：

1. １つの文の１・２語だけを強調したい場合は *
2. １つの文全体を強調、または、ラベルは **

１の例：

1.6/en/book/primitive-types.md

You can access the fields in a tuple through a destructuring let. Here’s

２の例：

1.6/en/book/error-handling.md

In examples and quick 'n' dirty code. Sometimes you're writing examples

1.6/en/book/inline-assembly.md

Note: the examples here are given in x86/x86-64 assembly, but

14.3.3 エイリアス

の冒頭が

「データは一度にいくつでもイミュータブルに借用する『音』ができます」

となっています。

http://rust-lang-ja.org/rust-by-example/scope/borrow/alias.html

翻訳の問題ではないのでしょうが、読んでいて気になりましたので起票します。

fの値が→9にならないのは何故なんでしょう？アドレスを辿ると2^30-2になるのはわかるのですが、補足する説明が欲しいと思いました。

現時点で、列挙型 https://github.com/rust-lang-ja/the-rust-programming-language-ja/tree/master/1.6/ja/book/enums.md においては、scoped が「スコープされた」と訳されています。これは日本語として変なので、「スコープ化された」という訳にし、TranslationTable に追加することを提案します。（検索したところ、「スコープ化された」は既存の用例があるようです。）

フィーチャーというのは直感的に理解しにくい気がします。
ここは和製英語を使わずそのまま新機能と訳したほうがいい気がします。