Merge pull request Shopify#22 from kissybnts/kissybnts-patch-1

Fix some typos

Author: eapache

lang/TUTORIAL_JAPANESE.md

@@ -712,11 +712,11 @@ GraphQLの草案は素朴なものよりもかなり良くなっていますが
 `description`はすでに強い型付け（`String`ではなく`HTML`）がされており、またこれまで強い型付けを議論してきました。
 しかし、繰り返しになりますが、入力は出力と少し異なる振る舞いを行うのです。
 
-強い型付けに対する値の検証は、ユーザ空間のコードが実行されるよりも前でに、GraphQLのレイヤーで実行されます。
+強い型付けに対する値の検証は、ユーザ空間のコードが実行されるよりも前に、GraphQLのレイヤーで実行されます。
 つまり、クライアントはGraphQLレイヤーにおける検証とビジネスドメインレイヤーにおける検証の両方で発生するエラーをそれぞれ対応する必要があるということです。
 （例えば、現状の許容ストレージ内で生成できるコレクションの上限に達した場合など）
 
-処理を簡単にするために、クライアント側で事前に検証を行うことが難しい場合には、我々は入力対して意図的に弱い型付けを行います。
+処理を簡単にするために、クライアント側で事前に検証を行うことが難しい場合には、我々は入力に対して意図的に弱い型付けを行います。
 これにより、ビジネスロジックレイヤーがすべての検証を行い、クライアントも一箇所から発生するエラーだけに対処するだけで済みます。
 
 *ルール #19: フォーマットが曖昧であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアントが非常にシンプルになる。*
@@ -725,7 +725,7 @@ GraphQLの草案は素朴なものよりもかなり良くなっていますが
 我々はroleの入力における`field`と`relation`フィールドに強い型付けをもったenumを用いています。
 例えば`DateTime`のような特定の値入力に対しても、強い型付けを使うことがあるでしょう。
 
-違いを生む要因はクライアント側検証の複雑さとフォーマットの曖昧さです。
+違いを生む要因はクライアント側の検証の複雑さとフォーマットの曖昧さです。
 HTMLはうまく定義されていて、明瞭な仕様がありますが、検証を行うには極めて複雑です。
 他方で日時や日付を表現する文字列には何百の表現方法があり、それらすべてが適切にシンプルなフォーマットをもっています。
 したがって、サーバーが期待するフォーマットを指定するために強い型付けを行うと便利です。
@@ -734,7 +734,7 @@ HTMLはうまく定義されていて、明瞭な仕様がありますが、検
 
 ### 入力: 構造 パート２
 
-つづいてupdate操作をみていきます。
+つづいてupdateのmutationをみていきます。
 
 ```graphql
 type Mutation {
@@ -842,8 +842,8 @@ type CollectionUpdatePayload {
 - ルール #16: 関連に対するmutationを分けて実装するときには、一度に複数の要素に対して実行することが便利かどうか検討すること。
 - ルール #17: アルファベット順でグループ化するために、mutationの接頭辞に操作対象のオブジェクト名を用いること（例えば`cancelOrder`ではなく`orderCancel`とする。）
 - ルール #18: mutation処理を遂行するうえで意味的に本当に必要である場合に限り、入力フィールドを必須とすること。
-- ルール #19: フォーマットが曖昧であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアント非常にシンプルになる。
-- ルール #20: フォーマットが曖昧でクライアント側検証がシンプルな場合は強い型付け（`String`ではなく`DateTime`）を行うこと。型付けにより明確さを得られ、クライアントにより厳しい入力値管理（フリーテキスト入力ではなくカレンダーウィジェットを用いる）を促せる。
+- ルール #19: フォーマットが曖昧であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアントが非常にシンプルになる。
+- ルール #20: フォーマットが曖昧でクライアント側の検証がシンプルな場合は強い型付け（`String`ではなく`DateTime`）を行うこと。型付けにより明確さを得られ、クライアントにより厳しい入力値管理（フリーテキスト入力ではなくカレンダーウィジェットを用いる）を促せる。
 - ルール #21: たとえいくつかのフィールドの必須制約を緩和する必要があっても、重複を減らすためにmutationの入力を構造化すること。
 - ルール #22: mutationはビジネスロジックレベルのエラーを`userErrors`フィールドに入れて返すこと。トップレベルのエラーフィールドはクライアントおよびサーバーレベルのエラーのために残しておくこと。
 - ルール #23: すべてのエラーケースおいて返せる特定の値がないのであれば、mutationが返すほとんどのフィールドはNullableであること。