Fixed anchors and invalid links (#548)

docs/ja/community/extensions/flex.md

@@ -22,7 +22,7 @@ GTFS Flex は、デマンド レスポンシブ交通サービスの発見可能
 
 詳細については、[元の提案](https://github.com/MobilityData/gtfs-flex/blob/master/spec/reference.md)および[問題#382](https://github.com/google/transit/issues/382)(スコープを変更したためクローズ)を参照してください。
 
-6 月 28 日の作業会議では、グループ コミュニティ間で、現在生成および消費されているすべてのフィールドをカバーするイテレーションを行うことが合意されました。したがって、[採用トラッカー](#adoption-tracker)で`**議論中**`と表示されるすべてのフィールドがこのPRに含まれています。
+6 月 28 日の作業会議では、グループ コミュニティ間で、現在生成および消費されているすべてのフィールドをカバーするイテレーションを行うことが合意されました。したがって、[採用トラッカー](#_3)で`**議論中**`と表示されるすべてのフィールドがこのPRに含まれています。
 
 このPRの変更点は次のとおりです。
 

docs/ja/community/governance/gtfs-realtime-amendment-process.md

@@ -12,12 +12,12 @@ GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS
 
 ## 実験的フィールド
 1.コミュニティが (a) 提案フィールドが有用であると思われること、および (b) フィールドのタイプ (`optional`と`repeated`、 `string`と`int`と`bool`) について合意に達した場合、 GTFS realtimemessageにフィールド番号が割り当てられ、[.proto file](../../../documentation/realtime/proto/) と、これが将来変更されるしてもよい*試験的* フィールドであることを示すドキュメントが必要です。
-      - 合意は、以下の [仕様修正プロセス](#specification-amendment-process) と同じ議論と投票プロセスを通じて達成されますが、承認には全員一致の同意ではなく、80% の賛成票のみが必須です。
+      - 合意は、以下の [仕様修正プロセス](#_2) と同じ議論と投票プロセスを通じて達成されますが、承認には全員一致の同意ではなく、80% の賛成票のみが必須です。
       - 新しい *試験的* フィールドの使用を希望するGTFS realtimeプロデューサーとコンシューマーは、新しいフィールドを含む .proto ファイルを使用してライブラリを再生成し (たとえば、Google は [gtfs-realtime-bindings ライブラリ](https://github.com/google/gtfs-realtime-bindings) を更新します)、ライブ データを使用してフィールドに入力および解析を開始します。
-      - *試験的* フィールドが価値があり、プロデューサーとコンシューマーの両方がフィールドを使用していることを確認したら、以下の [仕様修正プロセス](#specification-amendment-process) に従います。 
-      - *実験的* フィールドが、*実験的* フィールドとして承認されてから 2 年以内に [仕様修正プロセス](#specification-amendment-process) で採用されない場合は、[.proto ファイル](../../../documentation/realtime/proto/) ファイル内のフィールド値の横に`[deprecated=true]`を追加して非推奨になります`[deprecated=true]` ( `RESERVED`ではなく) を使用することで、すでにフィールドを採用しているプロデューサーとコンシューマーは、フィールドを使用から削除する必要がなくなります。さらに、フィールドは、 [仕様修正プロセス](#specification-amendment-process) 後の後続の投票で承認された場合 (追加のプロデューサーやコンシューマーがフィールドの使用を開始した場合など)、将来的に`非推奨ではなくなる`可能性があります。
+      - *試験的* フィールドが価値があり、プロデューサーとコンシューマーの両方がフィールドを使用していることを確認したら、以下の [仕様修正プロセス](#_2) に従います。 
+      - *実験的* フィールドが、*実験的* フィールドとして承認されてから 2 年以内に [仕様修正プロセス](#_2) で採用されない場合は、[.proto ファイル](../../../documentation/realtime/proto/) ファイル内のフィールド値の横に`[deprecated=true]`を追加して非推奨になります`[deprecated=true]` ( `RESERVED`ではなく) を使用することで、すでにフィールドを採用しているプロデューサーとコンシューマーは、フィールドを使用から削除する必要がなくなります。さらに、フィールドは、 [仕様修正プロセス](#_2) 後の後続の投票で承認された場合 (追加のプロデューサーやコンシューマーがフィールドの使用を開始した場合など)、将来的に`非推奨ではなくなる`可能性があります。
 
- 1.新しいフィールドが単一のプロデューサーに固有であると見なされる場合、またはデータ タイプに関して紛争がある場合は、プロデューサーに [カスタム拡張機能](#extensions) を割り当てて、プロデューサーが独自のフィードでフィールドを使用できるようにします。可能であれば、拡張機能を避け、多くの事業者に役立つフィールドをメイン仕様に追加して、断片化を回避し、コンシューマーが仕様のさまざまな拡張機能をサポートするための余分な作業を回避するべきである。
+ 1.新しいフィールドが単一のプロデューサーに固有であると見なされる場合、またはデータ タイプに関して紛争がある場合は、プロデューサーに [カスタム拡張機能](#_4) を割り当てて、プロデューサーが独自のフィードでフィールドを使用できるようにします。可能であれば、拡張機能を避け、多くの事業者に役立つフィールドをメイン仕様に追加して、断片化を回避し、コンシューマーが仕様のさまざまな拡張機能をサポートするための余分な作業を回避するべきである。
 
 ## 仕様修正プロセス
 1. プロトコル定義、仕様、ドキュメント ファイル (翻訳を除く) の関連部分をすべて更新した git ブランチを作成します。
@@ -42,7 +42,7 @@ GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS
   - 投票が否決された場合、アドボケートは提案の作業を続行するか、提案を放棄するかを選択してもよいアドボケートのどちらの決定も、[GTFS realtimeメーリング リスト](https://groups.google.com/forum/#!forum/gtfs-realtime) で発表するしなければならない。
   - アドボケートが提案の作業を続行する場合は、いつでも新しい投票を呼びかけることができます。
 1. 30 暦日間非アクティブのままになっているpull requestはすべてクローズされます。pull requestがクローズされると、対応する提案は放棄されたものとみなされます。アドボケートは、会話を継続または維持したい場合は、いつでもpull requestを再開してもよい。 
-  - 提唱者は、公式仕様の一部としてではなく、[カスタム拡張機能](#extensions)として機能を実装することを選択してもよい。
+  - 提唱者は、公式仕様の一部としてではなく、[カスタム拡張機能](#_4)として機能を実装することを選択してもよい。
 1.提案が承認された場合:
   - Google は、pull requestの投票されたバージョンをマージし (貢献者が [CLA](https://github.com/google/transit/blob/master/CONTRIBUTING.md) に署名している場合)、5 営業日以内にpull requestを実行することに尽力します。
   - Google は、[https://github.com/google/gtfs-realtime-bindings](https://github.com/google/gtfs-realtime-bindings) リポジトリをタイムリーに更新することに尽力します。提案の結果である gtfs-realtime-bindings へのコミットでは、提案のpull requestを参照するするべきである。
@@ -53,9 +53,9 @@ GTFSGTFS realtime仕様は固定されたものではありません。GTFSGTFS
 GTFS realtimeの当初のビジョンを維持するために、仕様を拡張する際に考慮すべき基本原則がいくつか確立されています。**フィードは、リアルタイムで効率的に生成および消費できる必要がするべきである。**リアルタイム情報は、効率的な処理を必要とする継続的かつ動的なデータ ストリームです。プロトコル バッファを仕様のベースとして選択したのは、開発者の使いやすさとデータ転送の効率性の点で適切なトレードオフを提供するためです。GTFS とは異なり、多くの事業者がGTFS realtimeフィードを手動で編集するとは考えられません。プロトコル バッファの選択は、ほとんどのGTFS realtimeフィードがプログラムによって生成および消費されるという結論を反映しています。**この仕様は乗客情報に関するものです。**以前の GTFS と同様に、 GTFS realtimeは主に乗客情報に関係しています。つまり、仕様には何よりもまず、乗客向けのツールを強化するのに役立つ情報が含まれてするべきである。交通事業者がシステム間で内部的に送信したい運用指向の情報が大量に存在する可能性がしてもよいます。GTFSGTFS realtimeはその目的を想定しておらず、より適切な運用指向のデータ標準が他にも存在する可能性があります。**仕様の変更は下位互換性を保つするべきである。**仕様に機能を追加するときは、既存のフィードを無効にするような変更は避けたいと考えています。既存のフィード パブリッシャーがフィードに機能を追加したいと思うようになるまで、余分な作業を発生させたくありません。また、可能な限り、既存のパーサーが新しいフィードの古い部分を引き続き読み取れるようにしたいと考えています。プロトコル バッファを拡張するための規則により、ある程度の後方互換性が強制されます。ただし、後方互換性が損なわれる可能性のある既存のフィールドの意味の変更は避けたいと考えています。**推測による機能は推奨されません。**新しい機能を追加すると、フィード作成と読み取りが複雑になります。そのため、有用であることがわかっている機能を追加するように注意する必要があります。理想的には、新しい機能を使用する実際の交通事業者のデータを生成し、それを読み取り、表示するソフトウェアを作成することで、提案はすべてテストされます。
 
 ## 拡張機能
-プロデューサーがGTFS realtimeフィードにカスタム情報を追加できるようにするために、[プロトコル バッファの拡張機能](https://developers.google.com/protocol-buffers/docs/proto#extensions) を活用します。拡張機能を使用すると、プロトコル バッファ message 内に名前空間を定義できます。これにより、サードパーティの開発者は、元の proto 定義を変更することなく、追加のフィールドを定義できます。
+プロデューサーがGTFS realtimeフィードにカスタム情報を追加できるようにするために、[プロトコル バッファの拡張機能](https://developers.google.com/protocol-buffers/docs/proto#_4) を活用します。拡張機能を使用すると、プロトコル バッファ message 内に名前空間を定義できます。これにより、サードパーティの開発者は、元の proto 定義を変更することなく、追加のフィールドを定義できます。
 
-可能な場合は拡張機能を避け、多くの事業者にとって有用なフィールドをメインの仕様に追加して、仕様の断片化と、仕様のさまざまな拡張機能をサポートするための消費者の余分な作業を回避するするべきであるがあります。拡張IDをリクエストする前に、プロデューサーは仕様にフィールドを追加することを提案するするべきである([GTFS realtimeへの新しいフィールドの追加](#adding-new-fields-to-gtfs-realtime)を参照)
+可能な場合は拡張機能を避け、多くの事業者にとって有用なフィールドをメインの仕様に追加して、仕様の断片化と、仕様のさまざまな拡張機能をサポートするための消費者の余分な作業を回避するするべきであるがあります。拡張IDをリクエストする前に、プロデューサーは仕様にフィールドを追加することを提案するするべきである([GTFS realtimeへの新しいフィールドの追加](#gtfs-realtime_1)を参照)
 
 9000～9999 の範囲内の拡張 ID は、GTFS-rt プロデューサーによるプライベート使用のために予約されています。これらの ID は、組織内で情報を伝達するためにのみ使用してください。この範囲の拡張は、パブリック フィードでは**使用しないでください**。
 

docs/ja/documentation/realtime/feed-entities/trip-updates.md

@@ -24,7 +24,7 @@
 
 各 [StopTimeUpdate](../../reference/#message-stoptimeupdate) は停留所にリンクされています。通常、これは GTFS stop_sequence または GTFS stop_id を使用して行うことができます。ただし、GTFS trip_id のない便の更新を提供する場合は、stop_sequence に値がないため、stop_id を指定する必要があります。stop_id は GTFS の stop_id を参照する必要があります。便中に同じ stop_id を複数回訪問する場合は、その便のその stop_id のすべての StopTimeUpdates で stop_sequence を指定する必要があります。
 
-更新では、[StopTimeEvent](../../reference/#message-stoptimeevent) を使用して、[StopTimeUpdates](../../reference/#message-stoptimeupdate) の停留所での **到着** および/または **出発** の正確なタイミングを提供できます。これには絶対的な**時間**または**遅延**（つまり、予定時刻からの秒単位のオフセット）のいずれかを含める必要があります。遅延は、運行更新が定期運行の GTFS 運行を参照する場合にのみ使用できます。頻度ベースの運行ではありません。この場合、時間は予定時刻 + 遅延に等しくする必要があります。[StopTimeEvent](../../reference/#message-stoptimeevent) とともに予測の**不確実性** を指定することもできます。これについては、ページの下の [不確実性](#uncertainty) セクションで詳しく説明します。
+更新では、[StopTimeEvent](../../reference/#message-stoptimeevent) を使用して、[StopTimeUpdates](../../reference/#message-stoptimeupdate) の停留所での **到着** および/または **出発** の正確なタイミングを提供できます。これには絶対的な**時間**または**遅延**（つまり、予定時刻からの秒単位のオフセット）のいずれかを含める必要があります。遅延は、運行更新が定期運行の GTFS 運行を参照する場合にのみ使用できます。頻度ベースの運行ではありません。この場合、時間は予定時刻 + 遅延に等しくする必要があります。[StopTimeEvent](../../reference/#message-stoptimeevent) とともに予測の**不確実性** を指定することもできます。これについては、ページの下の [不確実性](#_3) セクションで詳しく説明します。
 
 各 [StopTimeUpdate](../../reference/#message-stoptimeupdate) のデフォルトのスケジュール関係は**スケジュール** です。（これは、運行のスケジュール関係とは異なることに注意してください）。停留所点で停車しない場合はこれを**スキップ** に変更できます。運行の一部にリアルタイム データしかない場合は**データなし** に変更できます。