Merge pull request semver#1 from studiomohawk/review/ja-translation

fix few translation

lang/jp/index.md

@@ -22,16 +22,16 @@ title: セマンティック バージョニング 2.0.0
 
 ソフトウェア・マネージメントの世界には、『依存性地獄』と呼ばれる恐ろしいものがあります。あなたのシステムが大きく成長すればするほど、さまざまなパッケージを組む込めば組み込むほど、いつか自分が地獄の底にいることに気づくでしょう。
 
-多くの依存性を有しているシステムにとって、新しいバージョンがリリースされることは悪夢でしかありません。もし非常にタイトに依存関係を指定しているのなら、あなたのシステムはバージョン・ロック（すべての依存パッケージを新しくしない限り、アップグレードできない）しなければなりません。 逆に、依存性をあまりにも緩く管理していれば、バージョンが複雑に絡まり合い痛い目にあうことは避けられないでしょう（合理性よりも将来のバージョンとの互換性を気にすることになるでしょう）。依存性地獄とは、あなたのプロジェクトでバージョンロックまたはバージョン混乱に陥ることで、プロジェクトに支障をきたすことを指します。
+多くの依存性を有しているシステムにとって、新しいバージョンがリリースされることは悪夢でしかありません。厳密に依存関係を指定してしまうと、システムはバージョン・ロック（すべての依存パッケージを新しくしない限り、アップグレードできない）の危機にさらされてしまいます。反対に、依存指定を緩く管理しすぎると、バージョンが複雑に絡まり合い、痛い目にあうことは避けられないでしょう（合理性よりも将来のバージョンとの互換性を気にすることになるでしょう）。依存性地獄とは、あなたのプロジェクトでバージョン・ロックまたはバージョン混乱に陥ることで、プロジェクトに支障をきたすことを指します。
 
-この問題の解決策として、私はシンプルなルールセットとバージョン・ナンバーをどのように割り当て、上げていくのかについて必要条件を定義すべきだと提案します。これらのルールは既存のクローズドまたはオープンソースプロジェクトで普及している一般的な（必ずしもそうであるとは限りませんが）プラクティスをもとに作られています。このルールを利用するには、まずはパブリックなAPIを宣言する必要があります。これはドキュメントに記載されるか、コード自体で表現しているかもしれません。とにかく、APIが明確かつ正確であることは非常に重要な事です。一度、パブリックなAPIを宣言してしまえば、それを変更する際にはルールに従ってバージョン番号を上げなければなりません。つまり、X.Y.Z（メジャー.マイナー.パッチ）のバージョン形式を遵守しなければなりません。APIに影響を及ぼさないバグ修正はパッチバージョンを、後方互換性を保ちつつAPIを変更・追加した場合はマイナーバージョンを、後方互換性のないAPIの変更はメジャーバージョンを上げます。
+この問題の解決策として、私はシンプルなルールセットとバージョン・ナンバーをどのように割り当て、バージョンを上げていくのかについての必要要件を提案します。これらのルールは既存のクローズドまたはオープンソースプロジェクトで普及している一般的な（必ずしもそうであるとは限りませんが）プラクティスをもとに作られています。このシステムを利用するために、まずはパブリックなAPIを宣言する必要があります。これはドキュメントに記載されるか、コード自体で宣言するかどちらかが必要になります。とにかく、APIが明確かつ正確であることは非常に重要です。パブリックなAPIを宣言したら、それを変更する際にはルールに従ってバージョン番号を上げなければなりません。つまり、X.Y.Z（メジャー.マイナー.パッチ）のバージョン形式を遵守しなければなりません。APIに影響を及ぼさないバグ修正はパッチバージョンを、後方互換性を保ちつつAPIを変更・追加した場合はマイナーバージョンを、後方互換性のないAPIの変更はメジャーバージョンを上げます。
 
 私はこのシステムを『セマンティック バージョニング』と呼び、このスキームに従えば、あるバージョーンのコードが次のバージョンへの変更された際に何が変更されたのかユーザーに伝えることができます。
 
 セマンティックバージョニング仕様書 (SemVer)
 ------------------------------------------
 
-この文書における各キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、「必要とされています（REQUIRED）」、「することとします(SHALL)」、「しないこととします（SHALL NOT）」、「するべきです（SHOULD）」、「するべきではありません（SHOULD NOT）」、「勧められています（RECOMMENDED）」、「してもよいです（MAY）」、「オプションです（OPTIONAL）」は、[RFC 2119](http://tools.ietf.org/html/rfc2119)に記載されている内容に従い解釈してください。
+この文書における各キーワード「しなければなりません（MUST）」、「してはなりません（MUST NOT）」、「要求されている（REQUIRED）」、「することになる(SHALL)」、「しすることはない（SHALL NOT）」、「する必要がある（SHOULD）」、「しないほうがよい（SHOULD NOT）」、「推奨される（RECOMMENDED）」、「してもよいです（MAY）」、「選択できる（OPTIONAL）」は、[RFC 2119](http://tools.ietf.org/html/rfc2119)に記載されている内容に従い解釈してください。
 
 1. セマンティック バージョニングを適用するソフトウェアはパブリックAPIを宣言しなければなりません（MUST）。このAPIはコード自体で表現されているかもしれませんし、明確に文書として存在してるかもしれません。どちらにせよ、正確かつ漏れがないようにするべきです。
 
@@ -60,11 +60,11 @@ title: セマンティック バージョニング 2.0.0
 なぜセマンティック バージョニングを使用するのか？
 ----------------------------
 
-このアイデアは新しいものでもなければ、革新的なものでもありません。実際、みなさんも似たような取り組みを既に行っているかもしれません。問題は『似ている』のでは不十分だということです。正式な仕様書による取り決めがなければ、バージョンナンバーは依存性の管理において基本的には無意味です。上記のアイデアに対して名前と正確な定義を与えることよって、あなたの開発するソフトウェアにおいて、あなたの意図がユーザーに対して伝わりやすくなることでしょう。一度、これらの意図を正確にしてしませば、柔軟な（しかし、柔軟すぎてはいけない）依存性の仕様を作ることができます。
+このアイデアは新しいものでもなければ、革新的なものでもありません。実際、みなさんも似たような取り組みを既に行っているかもしれません。問題は『似ている』のでは不十分だということです。正式な仕様書による取り決めがなければ、バージョンナンバーは依存性の管理において基本的には無意味です。上記のアイデアに対して名前と正確な定義を与えることよって、あなたの開発するソフトウェアにおいて、あなたの意図がユーザーに対して伝わりやすくなることでしょう。一度、これらの意図を正確にしてしまえば、柔軟な（しかし、柔軟すぎてはいけない）依存性の仕様を作ることができます。
 
-単純な例として、セマンティックバージョニングがどのように依存性地獄を過去のものとしたか説明します。『Firetruck』と呼ばれるライブラリについて考えてみましょう。それはセマンティックバージョニングされた『Ladder』というパッケージを必要とします。Firetruckを作成した時、Ladderはバージョン3.1.0でした。Firetruckは、バージョン3.1.0時に導入されたいくつかの機能を使用してるので、Ladderが3.1.0以上4.0.0未満の範囲で安全に依存性を指定できます。Ladderのバージョン3.1.1と3.2.0が利用可能になった時、それらをパッケージ管理に取り込んでリリースすることができ、それらが既存の依存するソフトウェアと互換性があるということは明確です。
+単純な例として、セマンティックバージョニングがどのように依存性地獄を過去のものとするかについて説明します。『Firetruck』と呼ばれるライブラリについて考えてみましょう。それはセマンティックバージョニングされた『Ladder』というパッケージを必要とします。Firetruckを作成した時、Ladderはバージョン3.1.0でした。Firetruckは、バージョン3.1.0時に導入されたいくつかの機能を使用してるので、Ladderが3.1.0以上4.0.0未満の範囲で安全に依存性を指定できます。Ladderのバージョン3.1.1と3.2.0が利用可能になった時、それらをパッケージ管理に取り込んでリリースすることができ、それらが既存の依存するソフトウェアと互換性があるということは明確です。
 
-賢明な開発者であれば、もちろんパッケージがアップグレードされたのならその機能を使ってみたいと思うはずでしょう。しかし、この世界は混沌としていますがそれを気にする必要性はありません。セマンティックバージョニングを実践することで、新しい依存パッケージを巻き込むことなく、まともな方法でリリース、アップグレードすることができ、手間と時間を節約してくれることでしょう。
+賢明な開発者であれば、もちろんパッケージがアップグレードされたのならその機能を使ってみたいと思うはずでしょう。しかし、この現実は混沌としていて、我々が出来ることとといったら、慎重になることくらいです。セマンティックバージョニングを実践することで、新しい依存パッケージを巻き込むことなく、まともな方法でリリース、アップグレードすることができ、手間と時間を節約してくれることでしょう。
 
 もし全面的に同意できると感じたのなら、セマンティックバージョニングを実践していることを宣言し、ルールを守って下さい。それからあなたのREADMEからこのWebサイトにリンクしてください、そうすれば、他の人がこのルールを知り、役立てることができるでしょう。
 
@@ -106,7 +106,7 @@ FAQ
 
 ### どのように非推奨機能を扱えばよいでしょうか？
 
-既存機能を廃止予定にするのはソフトウェア開発においてはふつうのコトであり、開発を進めるうえでよく必要となります。パブリックAPIの一部を非推奨にしたい場合、2つのことをすべきです。第一にユーザーに知らせるためにドキュメントを更新して下さい。次に非推奨機能を残したまま新しいマイナーバージョンをリリースして下さい。完全に非推奨機能を削除しメジャーバージョンをリリースする前に、ユーザーがスムーズに新しいAPIに移行できるように少なくとも1回のマイナーバージョン（非推奨機能を含んだ）をリリースして下さい。
+既存機能を廃止予定にするのはソフトウェア開発においては普通の事であり、開発を進める上で頻繁に必要となります。パブリックAPIの一部を非推奨にしたい場合、2つのことをすべきです。第一にユーザーに知らせるためにドキュメントを更新して下さい。次に非推奨機能を残したまま新しいマイナーバージョンをリリースして下さい。完全に非推奨機能を削除しメジャーバージョンをリリースする前に、ユーザーがスムーズに新しいAPIに移行できるように少なくとも1回のマイナーバージョン（非推奨機能を含んだ）をリリースして下さい。
 
 ### semvarのバージョン文字列に限度はありますか？
 
@@ -123,4 +123,4 @@ FAQ
 ライセンス
 -------
 
-[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)
+[Creative Commons - CC BY 3.0](http://creativecommons.org/licenses/by/3.0/)