Modify for accurate translation

Author: nakaokat

lang/TUTORIAL_JAPANESE.md

@@ -842,7 +842,7 @@ type CollectionUpdatePayload {
 - ルール #16: 関連に対するmutationを分けて実装するときには、一度に複数の要素に対して実行することが便利かどうか検討すること。
 - ルール #17: アルファベット順でグループ化するために、mutationの接頭辞に操作対象のオブジェクト名を用いること（例えば`cancelOrder`ではなく`orderCancel`とする。）
 - ルール #18: mutation処理を遂行するうえで意味的に本当に必要である場合に限り、入力フィールドを必須とすること。
-- ルール #19: フォーマットが明確であったり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアントが非常にシンプルになる。
+- ルール #19: フォーマットが明確であり、クライアント側の検証が複雑な場合には、入力に対して弱い型付け（`Email`ではなく`String`）を行うこと。これによりサーバーは一度にすべての検証を実行し、単一のフォーマットでエラーを報告することになり、結果としてクライアントが非常にシンプルになる。
 - ルール #20: フォーマットが曖昧でクライアント側の検証がシンプルな場合は強い型付け（`String`ではなく`DateTime`）を行うこと。型付けにより明確さを得られ、クライアントにより厳しい入力値管理（フリーテキスト入力ではなくカレンダーウィジェットを用いる）を促せる。
 - ルール #21: たとえいくつかのフィールドの必須制約を緩和する必要があっても、重複を減らすためにmutationの入力を構造化すること。
 - ルール #22: mutationはビジネスロジックレベルのエラーを`userErrors`フィールドに入れて返すこと。トップレベルのエラーフィールドはクライアントおよびサーバーレベルのエラーのために残しておくこと。