3

世界中で使用することを目的としたWebサイトに、複数の言語でテキストを保存（および表示）するにはどうすればよいですか？コンテンツは主に500語以上の記事の形式ですが、各ページのテキストの小さな断片も翻訳する必要があります（「この記事を印刷する」や「メニューに戻る」など）。

複数の言語を処理するCMSパッケージがいくつかあることは知っていますが、既存のASPシステムとも統合する必要があるため、そのようなソリューションは無視しています。

私が抱えている懸念の1つは、外国のユーザーであっても、Googleがページを見つけられるようにする必要があるということです。処理日と通貨の問題についてはあまり心配していません。

自分のデバイスに任せて、これを機能させる方法を発明しますが、最終的には災害につながるのではないかと心配しています。未熟なアイデアではなく、実際のプロジェクトで実際に使用したプロフェッショナルなソリューションを知りたいです。どうもありがとう。

私はRESXファイルを調べましたが、最も些細な翻訳ソリューション以外のすべてには不適切であると感じました（誰かが知りたい場合は詳しく説明します）。

Googleはテキストの翻訳を手伝ってくれますが、保存/提示はしません。

プレゼンテーションに独自のコードに依存する多言語プロジェクトに取り組んだ人はいますか？

次の方法でコンテンツを提供することについて何か考えはありますか？どれが最適ですか？

（これらは実際のURLではありません。例を示しているだけです）

4

7 に答える 7

5

まず、すべての言語のすべてのコードを1つのドメインに配置します。これは、Googleのランク付けに役立ちます。

ローカリゼーションはデータベースに保存されていますが、Webアプリケーションにキャッシュされている完全な多言語システムがあります。

ローカリゼーションを表示したい場合は、次を使用します。

<%$ Resources: LanguageProvider, Path/To/Localisation %>

次に、web.configで：

<globalization resourceProviderFactoryType="FactoryClassName, AssemblyName"/>

FactoryClassNameResourceProviderFactory次に、実際の動的機能を提供するために実装します。ローカリゼーションは、文字列キー「Path / To/Localisation」でDBに保存されます

ローカライズされた値をキャッシュすることが重要です。各ページで多数のDBルックアップを使用したくない場合は、パフォーマンスの問題なしに数千のローカライズされた文字列をキャッシュします。

ユーザーの現在のブラウザーのローカリゼーションを使用して、提供する言語を選択します。

于 2008-09-23T11:12:42.440 に答える
2

GNU Gettextプロジェクトをチェックアウトすることをお勧めします - 少なくとも何かを始めるためのものです。

プロジェクトに関する情報を追加するために編集されました:

C++/MFC や J2EE/JSP など、さまざまなテクノロジで Gettext テクノロジを使用する複数の多言語プロジェクトに取り組んできましたが、すべてうまくいきました。ただし、もちろん、ローカライズされたデータを表示するには、独自のコードを作成/検索する必要があります。

于 2008-09-16T13:53:07.413 に答える
1

.Netを使用している場合は、1つ以上のリソースファイル（.resx）を使用することをお勧めします。これに関するドキュメントはMSDNにたくさんあります。

于 2008-09-16T13:52:14.887 に答える
1

ほとんどの一般的なプログラミングの質問と同様に、ニーズによって異なります。

静的テキストの場合、RESX ファイルを使用します。.Net プログラマーである私にとって、これらは使いやすく、.Net Framework はそれらを適切にサポートしています。

動的テキストの場合、特にサイトの管理者が非開発者になる場合は、そのような情報をデータベースに保存する傾向があります。過去に、言語列を追加して言語ごとに異なるエントリを作成するか、言語固有のテキストを格納する別のテーブルを作成するという 2 つのアプローチを使用しました。

最初のアプローチの表は次のようになります。

記事ID | 言語 ID | 言語固有の記事のテキスト | 作成者 | 作成日

これは、特定の記事に対して異なるエントリを作成でき、これらの異なるエントリに関連付けられたデータ (更新されたタイムスタンプなど) を同期しておく必要がない場合に機能します。

もう 1 つの方法は、言語に固有でないテキスト (ID、作成日、作成ユーザー、更新日など) 用のテーブルと、言語固有のテキストを含む別のテーブルの 2 つの別個のテーブルを用意することです。したがって、テーブルは次のようになります。

最初のテーブル: 記事 ID | 作成者 | 作成日 | 更新者 | 更新日

2 番目のテーブル: 記事 ID | 言語 ID | 言語固有の記事テキスト

私にとっての問題は、言語に依存しないデータを更新することです。そのデータを更新している場合は、2 番目のアプローチに傾倒します。それ以外の場合は、最初のアプローチの方が単純だと考えて、最初のアプローチを使用します (KISS の原則を忘れないでください)。

于 2008-09-16T15:12:50.733 に答える
0

素晴らしい質問です。

私が作成したウェブサイト (プロフィールのリンク) でこの問題を解決するには、一般的なテンプレートをオンザフライで翻訳し、要求された (または Apache が Accept-Language から推測した) 言語から特定のコンテンツ ページを挿入する自家製の Python 3 スクリプトを使用しました。

Python を学び、コンテンツ ページを作成するための独自のミニ ライブラリを作成することができたので、とても楽しかったです。1 つの欠点は、ホスティングに Python 3 がなかったことですが、スクリプトで静的 HTML を生成し (元の HTML はユーザー エージェントを調べていました)、それをサーバーにアップロードしました。これは今のところ機能しており、サイトの新しい言語バージョンを作成するのは簡単です:)

この方法の最大の欠点は、最初から書くのに時間がかかることです。必要に応じて、私に連絡してください。私のスクリプトの使用をお手伝いします:)

于 2009-05-31T23:37:07.873 に答える
0

記事のコンテンツが翻訳されることだけが心配で、完全に統合されたオプションは必要ない場合は、以前にGoogle 翻訳を使用したことがありますが、小規模であれば問題なく機能します。

于 2008-09-16T13:56:24.190 に答える