オリジナルに関連付けられた翻訳の技術的な実装は、ユーザースクリプト、アドオン、ブラウザー拡張機能です。 最悪の場合、テキスト構造のリンクがない場合、翻訳サイトへのリンクを表示し、オンライン翻訳者を使用して支援できます。
翻訳のデータのソースは何ですか？ ネットワークのさまざまな場所とそのコピーから既に利用可能な翻訳。 通信を確立するには、通信マップが必要です。これは、ソースマップで使用されているものと同じテクノロジーです。 対応ファイルは、翻訳がある場所または3番目の場所にある場合があります。 最後に、開始ランドマークが保存されている場所が必要です-翻訳および通信ファイルのデータを検索する場所に関する情報。 明らかに、これらは必要なリソースへのリンクのディレクトリになります。 ユーザーは、必要に応じてリンクとリソース自体のコピーを作成します。
情報表現のコンバーターは、非常によく似た問題を解決します。 彼らのタスクは、翻訳なしでテストを表示することですが、異なる構造設計（アグリゲーターのように関心のあるニュースを選択します）で、互換性のない形式と必要な更新を時間内に通知するために、情報を送信するフォームの変更を追跡します。 この場合、データを表示する形式はユーザーが選択します。これは、データが作成されたサイトの形式内で厳密に翻訳を表示するのに比べて、追加のタスクです。
私たちは、今日とは異なるインターネットでの作業の構造を取得します。 まず、ニュースの翻訳やドキュメントを表示するサイトは必要ありません。 そのようなサイトからの情報は非常に必要ですが、データの形式と元の構造にあります。 それらは、翻訳された情報を元のサイトに「戻す」ために、最初の段階で使用できます。 将来的には、登録せずに直接情報を提供するリソース（データ、通信ファイル、オリジナルの構造を制御するデータ）で作業することが便利です。
オリジナルがアクセスから消えたり、構造が予期せずに変更されたりした場合、情報自体が関連する場合、使用を継続するにはその情報が必要になります。 したがって、サーバーまたは個々のコピーリソースは、ほぼP2Pのように、分散クライアントのネットワークの必要な機能を果たし、オフラインまたはイントラネットでの作業を支援すると同時に、この情報またはその情報の関連性を示します-ボリュームを保存する余裕がある人も重要なものをコピーします これは通常の人間の情報の保存と変わりません。進化の中でキャリアが生き残るのを助ける脳の原始的な性質です。
したがって、データネットワークは、元のソースが失われた場合のキャッシングおよびデータリカバリの機能と一緒に考慮されます。
別の機能は、表現変換システムです。 彼らはどれくらい必要ですか？ 一方で、サードパーティのリソースでの同じ翻訳は、プレゼンテーションで情報を提供できます。これは、さまざまなサイトでプレゼンテーションのデザインを単純にコピーするのに比べて、良い形とさえ考えられます。 さまざまなプレゼンテーションデザインは、情報構造（ドキュメント、書籍、ヘルプページ、ディスカッション）の表示に適していますか？ まず、元のデザインは情報の起源を強調しています。 設計がそれ自体の情報源のふりをしていない場合、誰もその情報源について誤解されません。 一方、プレゼンテーションの設計の不一致により、さまざまな知識分野のさまざまなソース（さまざまなAPIの説明、さまざまな辞書、類似のトピックに関する本など）を含む一般的なものを見ることは難しくなります。 プレゼンテーションの決定は、情報の受信者が行った方が良いです-彼は、元の形式と使用されている任意の形式の両方でそれを見ることができます。 形式がデータの一部を表示できない場合、表示ツールのタスクは表示形式でレポートすることです。 たとえば、エキゾチックなプレーヤーとそれに関連するデータ形式を表示できないことや、ノートを表示するスペースがないことについて。
独自の表現が最初に提供されなかったデータに対しても、独自の表現が必要です。 典型的な例は単純なRSSリストですが、元々どのエンジンにも結び付けられていなかった複雑な地図作成データや、さまざまな表示条件で異なるように表示される書籍や記事の構造があります。
このタスクの範囲全体で、翻訳は控えめですが目立つ場所を占めています。 他の読者グループによるテキストを理解するために必要です。 これらは必要な場所に存在し、翻訳メカニズムが提供されている場所に表示されます。 実際、これは、情報の表現の典型的な変換のためのメカニズムであり、サイトの設計と同じように注意を払って処理する必要があります。 ただし、これは、国際化が重要で削除できないコンポーネントであるサイトのバックエンドで感じられます。
表現を変換するための開発されたシステムの存在により、興味深い結果が生じます-現在説明されている別のサブシステムがそれを処理し、それを単一言語表現に「設定」して翻訳付きのフォーマットを与えるのに十分な場合、サイトの国際化はオプションになります。 翻訳は投稿のレベルでのみ重要であるため（場合によっては-はい、投稿のレイアウトは単語やフレーズの長さに依存しますが、これは投稿にも正確に当てはまります）。 翻訳システムと表現システムは、アーキテクチャの腸から取り除くことができます。 はい、サイト自体は多言語ユーザーを支援できますが、そのためにバックエンドを使用する必要はありません。
アドオンをインストールする必要が生じないようにするため（ただし、将来的にはブラウザモジュールになる可能性があります）、サイト自体が必要なスクリプトを送信して、翻訳と表現を表示できます。
検索エンジンの役割と場所
また、検索エンジンの一部が古風な形式のテキストのみを認識する場合、データ表現のみを使用してフロントエンドをある程度引き戻します。 彼らにとっては、サイトレベルでデータを表示する必要があります。 プログレッシブアプローチの場合（検索エンジン自体が構造の形式でデータを受信できます）、これは表示トレンドに対応し、コストを削減します。 もちろん、認識されたプレゼンテーション形式が表示された後にのみ。
翻訳に戻る
技術的にウェブサイトに翻訳を埋め込むには、ここで説明するいくつかのサブシステムが必要です。ウェブサイト表現のデータ構造の分析。 プレゼンテーションの整合性の制御。 変更について読者と翻訳者に知らせる。 通信ファイル（マップファイル）; 元のテキストの代わりにテキストを埋め込む。 または、オリジナルと翻訳の両方を再度生成して独自のビューを表示します。
オリジナルに埋め込むことの便利さは、マークアップとリンクが自動的にマッピングに表示され、読み上げや翻訳を妨げることなく、テキストの必要な部分を強調してリンクすることです。 サードパーティのテキストでのリンクとアクセントのサポートは、翻訳者にとって追加のコアではないタスクです。そのため、アクセントが枯渇した翻訳を頻繁に見ることができますが、リンクの実際のサポートに対する希望はまだありません。
このアプローチを使用すると、用語や略語の翻訳を読者の好みに合わせて使用でき、主題分野の特定の言語をサポートできることは興味深いことです。 たとえば、経験の浅い読者の場合は、略語を展開します。 また、非常に経験豊富な読者には、広告の削除方法と同様に、テキストからの「水分除去」を含めます。 結局のところ、セマンティック分析は、すでに翻訳に存在するマッピングファイルからの非常に小さなステップです。 誰かが翻訳に困惑している場合、適合テキストを作成するための用語マークにも困惑している可能性があります。または、プログラムがこれを自動的に実行しようとする場合があります。
言語学習システムもこのキッチンの近くにあります。 トレーニングシステムが読者のトレーニングレベルを把握している場合、学習に最適な未知の単語の割合がテストに残るように、未知の用語を読者に表示または翻訳できます。
専門知識にも同様の問題があります。初心者が難しい記事を読んだ場合、問題は多くの未知の用語やアイデアです。 適応されたテキスト、教科書は、読者から彼の知識のレベルについて学んだ（また、以前のレッスンとテストに基づいて得られた、主題分野で習得した概念からの特定のファイルでもある）この瞬間に気付くことができ、そうするはずです。 基本的なギャップ（関数型プログラミングの知識の欠如）のために読者が習得する準備ができていない場合、システムは必要なコースを受講するようにアドバイスし、通常の難易度を示します。
ご覧のとおり、このような翻訳システムを使用するかどうかの問題では、知識を獲得するための最も重要な要素の多くが、個人の知的活動に合わせて混合されています。 セマンティックWebのエコー、知識の普及、データのプレゼンテーション、そしてまさに基礎として-翻訳表示機能を使用した元の形式のソーステキストの控えめな置換です。
Web上のデータを表示および操作するシステムがこのようになることは非常に明白になっているため、このような翻訳システムの作成について考え始める必要があります。