changed folder name

docs/bugs.rst

@@ -6,69 +6,53 @@
 List of Known Bugs
 ##################
 
-Below, you can find a JSON-formatted list of some of the known security-relevant bugs in the
-Solidity compiler. The file itself is hosted in the `Github repository
-<https://github.com/ethereum/solidity/blob/develop/docs/bugs.json>`_.
-The list stretches back as far as version 0.3.0, bugs known to be present only
-in versions preceding that are not listed.
+以下でSolidityコンパイラのセキュリティに関連したバグのリストがJSON形式で取得できます。
+このファイル自身は `Github repository
+<https://github.com/ethereum/solidity/blob/develop/docs/bugs.json>`_ 内に格納されています。
+このリストはバージョン0.3.0まで遡って管理されますが、それより前のバージョンにのみ存在するバグについては記載されません。
 
-There is another file called `bugs_by_version.json
-<https://github.com/ethereum/solidity/blob/develop/docs/bugs_by_version.json>`_,
-which can be used to check which bugs affect a specific version of the compiler.
+`bugs_by_version.json <https://github.com/ethereum/solidity/blob/develop/docs/bugs_by_version.json>`_ という別のファイルもあります。
+これは、コンパイラの特定のバージョンに影響するバグをチェックするために使われます。
 
-Contract source verification tools and also other tools interacting with
-contracts should consult this list according to the following criteria:
+コントラクトソース検証ツールやコントラクトとやり取りするツールは、以下の基準に従いこのリストを参照する必要があります。
 
- - It is mildly suspicious if a contract was compiled with a nightly
-   compiler version instead of a released version. This list does not keep
-   track of unreleased or nightly versions.
- - It is also mildly suspicious if a contract was compiled with a version that was
-   not the most recent at the time the contract was created. For contracts
-   created from other contracts, you have to follow the creation chain
-   back to a transaction and use the date of that transaction as creation date.
- - It is highly suspicious if a contract was compiled with a compiler that
-   contains a known bug and the contract was created at a time where a newer
-   compiler version containing a fix was already released.
+ - リリースバージョンではなくnightlyビルドのコンパイラでコンパイルされたコントラクトは疑わしいです。
+   このリストはリリースされてないバージョンやnightlyビルドのバージョンは追随していないです。
+ - コントラクトが作成された時に、最新バージョンでコンパイルされていないコントラクトもまた、疑わしいです。
+   他のコントラクトから作成されたコントラクトには、creation chainを辿ってトランザクションまで戻り、creation dateとしてトランザクションの日付を使わなければいけません。
+ - 既知のバグが含まれたコンパイラでコンパイルされたコントラクトや、すでにリリースされた修正済みバグを含む新しいコンパイラで作られたコントラクトは非常に疑わしいです。
 
-The JSON file of known bugs below is an array of objects, one for each bug,
-with the following keys:
+既知のバグのJSONファイルはオブジェクトの配列になっており、それぞれのバグが以下のキーを持つ1つのオブジェクトです。
 
 name
-    Unique name given to the bug
+    バグに振られるユニークな名前
 summary
-    Short description of the bug
+    バグの短い説明
 description
-    Detailed description of the bug
+    バグの詳細な説明
 link
-    URL of a website with more detailed information, optional
+    より詳細な説明があるサイトのURL(任意)
 introduced
-    The first published compiler version that contained the bug, optional
+    バグを含む最初に公開されたコンパイラのバージョン(任意)
 fixed
-    The first published compiler version that did not contain the bug anymore
+    バグを含まない最初に公開されたコンパイラのバージョン(任意)
 publish
-    The date at which the bug became known publicly, optional
+    バグが公けに知られた日付(任意)
 severity
-    Severity of the bug: very low, low, medium, high. Takes into account
-    discoverability in contract tests, likelihood of occurrence and
-    potential damage by exploits.
+    バグの緊急度: very low, low, medium, high
+    コントラクトのテストでの発見可能性、発生頻度、悪用時に潜在被害を考慮してください。
 conditions
-    Conditions that have to be met to trigger the bug. Currently, this
-    is an object that can contain a boolean value ``optimizer``, which
-    means that the optimizer has to be switched on to enable the bug.
-    If no conditions are given, assume that the bug is present.
+    バグの発生条件。現在、booleanの ``optimizer`` を含められるオブジェクトです。
+    これはオプティマイザがバグを有効にするために切り替えられなければならない、という意味です。
+    conditionsが記載されていない場合、バグが存在するとみなされます。
 check
-    This field contains different checks that report whether the smart contract
-    contains the bug or not. The first type of check are Javascript regular
-    expressions that are to be matched against the source code ("source-regex")
-    if the bug is present.  If there is no match, then the bug is very likely
-    not present. If there is a match, the bug might be present.  For improved
-    accuracy, the checks should be applied to the source code after stripping
-    comments.
-    The second type of check are patterns to be checked on the compact AST of
-    the Solidity program ("ast-compact-json-path"). The specified search query
-    is a `JsonPath <https://github.com/json-path/JsonPath>`_ expression.
-    If at least one path of the Solidity AST matches the query, the bug is
-    likely present.
+    このフィールドは、スマートコントラクトがバグを含むかそうでないかを報告する様々なチェックを含みます。
+    最初のチェックタイプはJavascriptの正規表現です。これは、バグが存在するときにソースコード("source-regex")にたいして照合されるものです。
+    もし一致するものがなければ、このバグはほとんど発生しない可能性があります。
+    より正確にするため、チェックはコメントを取り除いた後のソースコードに適用されるべきです。
+    2番目のチェックタイプは、Solidityプログラム ("ast-compact-json-path") のcompact ASTにチェックされるパターンです。
+    検索クエリは、`JsonPath <https://github.com/json-path/JsonPath>`_ 式です。
+    もし、少なくともthe Solidity ASTのパスが1つでもクエリに一致した場合、このバグはおそらく存在します。
 
 .. literalinclude:: bugs.json
    :language: js

docs/common-patterns.rst

@@ -10,21 +10,11 @@ Common Patterns
 Withdrawal from Contracts
 *************************
 
-The recommended method of sending funds after an effect
-is using the withdrawal pattern. Although the most intuitive
-method of sending Ether, as a result of an effect, is a
-direct ``transfer`` call, this is not recommended as it
-introduces a potential security risk. You may read
-more about this on the :ref:`security_considerations` page.
-
-The following is an example of the withdrawal pattern in practice in
-a contract where the goal is to send the most money to the
-contract in order to become the "richest", inspired by
-`King of the Ether <https://www.kingoftheether.com/>`_.
-
-In the following contract, if you are usurped as the richest,
-you will receive the funds of the person who has gone on to
-become the new richest.
+発行の後にファンドを送る方法としてお勧めなのはwithdrawalパターンを使うことです。直接 ``transfer`` コールするのは直感的なEtherの送金方法ですが、潜在的にセキュリティリスクを実装することになるので、推奨しません。これに関しての詳しい情報は、:ref:`security_considerations` を読んでください。
+
+次の例はあるコントラクトにおける実際のwithdrawalパターンです。このコントラクトの目的は"richest"（ `King of the Ether <https://www.kingoftheether.com/>`_ に触発されました）になるためにたくさんのお金をコントラクトに送ることです。
+
+下記のコントラクトでは、richestの座を奪われたら、新しくrichestになった人のファンドを受け取れます。
 
 ::
 
@@ -61,7 +51,7 @@ become the new richest.
         }
     }
 
-This is as opposed to the more intuitive sending pattern:
+次は逆にもっと直感的な送金パターンです。
 
 ::
 
@@ -89,44 +79,25 @@ This is as opposed to the more intuitive sending pattern:
         }
     }
 
-Notice that, in this example, an attacker could trap the
-contract into an unusable state by causing ``richest`` to be
-the address of a contract that has a fallback function
-which fails (e.g. by using ``revert()`` or by just
-consuming more than the 2300 gas stipend transferred to them). That way,
-whenever ``transfer`` is called to deliver funds to the
-"poisoned" contract, it will fail and thus also ``becomeRichest``
-will fail, with the contract being stuck forever.
+気づいて頂きたいのは、この例では攻撃者が、``richest`` に、失敗する（例えば、``revert()`` を使ったり、2300ガス以上を消費したりすることで）フォールバックファンクションを持ったコントラクトアドレスを入れることで、通常ではない状態をコントラクトに仕込めるということです。こういう方法によって、"毒された"コントラクトにファンドを送るために ``transfer`` が呼ばれると常に失敗し、その結果、``becomeRichest`` が失敗し、コントラクトは永遠に動かなくなります。
 
-In contrast, if you use the "withdraw" pattern from the first example,
-the attacker can only cause his or her own withdraw to fail and not the
-rest of the contract's workings.
+一方、もし最初の例の"withdraw"パターンを使うと、攻撃者は自分のwithdrawの失敗しか起こせないので、他のコントラクトの機能は損なわれません。
 
 .. index:: access;restricting
 
 ******************
 Restricting Access
 ******************
 
-Restricting access is a common pattern for contracts.
-Note that you can never restrict any human or computer
-from reading the content of your transactions or
-your contract's state. You can make it a bit harder
-by using encryption, but if your contract is supposed
-to read the data, so will everyone else.
+アクセス制限はコントラクトの共通パターンです。他の人やコンピューターがトランザクションやコントラクトのステートを読み取ることを制限することはできないということを覚えておいてください。暗号化で少し難しくはできますが、もしコントラクトがデータを読み込めるなら、他の人もできます。
 
-You can restrict read access to your contract's state
-by **other contracts**. That is actually the default
-unless you declare your state variables ``public``.
+**他のコントラクト** によるあなたのコントラクトのステートへの読み込みのアクセスは制限できます。状態変数を ``public`` で宣言しなければ、これはデフォルトでそうなっています。
 
-Furthermore, you can restrict who can make modifications
-to your contract's state or call your contract's
-functions and this is what this section is about.
+さらに、誰があなたのコントラクトのステートを変更したり、ファンクションを呼び出したりできるか制限することができます。そしてこれがこのセクションで説明することです。
 
 .. index:: function;modifier
 
-The use of **function modifiers** makes these
-restrictions highly readable.
+**function modifiers** を使うことでこれらの制限をとても読みやすくします。
 
 ::
 
@@ -216,69 +187,40 @@ restrictions highly readable.
         }
     }
 
-A more specialised way in which access to function
-calls can be restricted will be discussed
-in the next example.
+どのファンクションコールへのアクセスが制限できるかというもっと特殊な方法は次の例で説明します。
 
 .. index:: state machine
 
 *************
 State Machine
 *************
 
-Contracts often act as a state machine, which means
-that they have certain **stages** in which they behave
-differently or in which different functions can
-be called. A function call often ends a stage
-and transitions the contract into the next stage
-(especially if the contract models **interaction**).
-It is also common that some stages are automatically
-reached at a certain point in **time**.
+コントラクトはよくステートマシンとして振舞います。つまり、異なる挙動をする、もしくは異なるファンクションがコールされるいくつかの **ステージ** を持っています。ファンクションコールはしばしばステージを終わらせ、コントラクトを次のステージへ以降させます（特にコントラクトに **相互作用** があった場合）。いくつかのステージは自動的にあるポイントに **そのうちに** なっていることもよくあります。
 
-An example for this is a blind auction contract which
-starts in the stage "accepting blinded bids", then
-transitions to "revealing bids" which is ended by
-"determine auction outcome".
+この例としてブラインドオークションのコントラクトがあります。このコントラクトでは"ブラインドビッドの承認"ステージから始まり、"オークションの結果"で終わる"ビッドの公開"に移行します。
 
 .. index:: function;modifier
 
-Function modifiers can be used in this situation
-to model the states and guard against
-incorrect usage of the contract.
+このシチュエーションで、ステートを作って、コントラクトの間違った使用法から守るため、ファンクションmodifierを使うことができます。
 
 Example
 =======
 
-In the following example,
-the modifier ``atStage`` ensures that the function can
-only be called at a certain stage.
+次の例では、modifier ``atStage`` はあるステージの時にのみファンクションが呼ばれるようにすることができます。
 
-Automatic timed transitions
-are handled by the modifier ``timeTransitions``, which
-should be used for all functions.
+自動でのある時間での変遷はmodifier ``timeTransitions`` でコントロールすることができ、全てのファンクションで使えます。
 
 .. note::
-    **Modifier Order Matters**.
-    If atStage is combined
-    with timedTransitions, make sure that you mention
-    it after the latter, so that the new stage is
-    taken into account.
+    **modifierの順番は重要です。**
+    atStageがtimedTransitionsと一緒にする場合、timedTransitionsの後にatStageを付けてください。そうすることで新しいステージが考慮されます。
+
 
-Finally, the modifier ``transitionNext`` can be used
-to automatically go to the next stage when the
-function finishes.
+最後に、modifier ``transitionNext`` はファンクションが終わった時に自動的に次のステージに行くために使用できます。
 
 .. note::
-    **Modifier May be Skipped**.
-    This only applies to Solidity before version 0.4.0:
-    Since modifiers are applied by simply replacing
-    code and not by using a function call,
-    the code in the transitionNext modifier
-    can be skipped if the function itself uses
-    return. If you want to do that, make sure
-    to call nextStage manually from those functions.
-    Starting with version 0.4.0, modifier code
-    will run even if the function explicitly returns.
+    **modifierはスキップされるかもしれません。**
+    これはSolidityバージョン0.4.0より前にのみ適用されます。modifierはファンクションコールを使うのではなく、単純にコードを別の所に書くことで適用されているので、もしファンクションがreturnを使っていたら、transitionNext内のコードはスキップされるかもしれません。もしスキップさせたくないのであれば、ファンクション内マニュアルでnextStageを呼び出してください。
+    バージョン0.4.0からはファンクションが明示的にreturnしていても、modifierコードは実行されます。
 
 ::
 

docs/contracts.rst

@@ -6,12 +6,7 @@
 Contracts
 ##########
 
-Contracts in Solidity are similar to classes in object-oriented languages. They
-contain persistent data in state variables and functions that can modify these
-variables. Calling a function on a different contract (instance) will perform
-an EVM function call and thus switch the context such that state variables are
-inaccessible. A contract and its functions need to be called for anything to happen.
-There is no "cron" concept in Ethereum to call a function at a particular event automatically.
+Solidityに置けるコントラクトはオブジェクト指向の言語におけるクラスに似ています。コントラクトは永続的な状態変数とそれを変更するファンクションを保持しています。異なるコントラクト上（インスタンス上）のファンクションコールはEVMのファンクションコールとなり、その結果コンテクストが変わり、状態変数にアクセスできなくなります。コントラクトとそのファンクションは呼び出さないと動きません。Ethereumには"cron"の様に特定のイベントで自動的にファンクションを呼び出す機能はありません。
 
 .. include:: contracts/creating-contracts.rst
 
@@ -31,4 +26,4 @@ There is no "cron" concept in Ethereum to call a function at a particular event
 
 .. include:: contracts/libraries.rst
 
-.. include:: contracts/using-for.rst
+.. include:: contracts/using-for.rst