23

私は 30 の言語に翻訳する必要があるソフトウェア プロジェクトに取り組んでいます。これは、文字列を変更すると、比較的高いコストが発生することを意味します。さらに、翻訳パッケージはさまざまな翻訳者が作業する必要があるため、翻訳は一夜にして行われるわけではなく、時間がかかる場合があります。

新しい機能を追加するのは、どういうわけか面倒です。実際に UI をコーディングする前に、必要なすべての文字列を考えることができますが、バグ修正や見落としのために新しい文字列を追加する必要がある場合もあります。

問題は、このすべてのプロセスをどのように管理するかということです。ソフトウェア プロジェクトにおける翻訳の影響を緩和する方法について何かヒントはありますか? 文字列に支配されるのではなく、文字列を支配するにはどうすればよいでしょうか?

編集: Java を使用しており、すべての文字列はリソース バンドルを使用して国際化されているため、問題は国際化そのものではなく、文字列の管理です。

4

11 に答える 11

13

あなたが国際化しているプラ​​ットフォームがわかりません。アプリケーションをil8nするための最良の方法について、以前に回答を書きました。asp.net アプリケーションをグローバル化するために知っておくべきことを参照してください。

とはいえ、翻訳自体を管理するのは大変です。問題は、複数のページで同じテキストを使用することです。ただし、フレームワークでは、そのテキストを 1 つのファイルに格納することしかサポートされていない場合があります (たとえば、asp.net のリソース ファイルでは、言語ごとに 1 つのリソース ファイルを使用することが推奨されます)。

物事を処理するために私たちが見つけた方法は、翻訳の中央データベース リポジトリを持つことでした。リソース ファイルからそのデータベースに翻訳をインポートし、そのデータベースからリソース ファイルに翻訳をエクスポートする小さな .net アプリケーションを作成しました。したがって、ビルド プロセスには、リソース ファイルをビルドするための追加の手順があります。

もう 1 つの問題は、翻訳を翻訳ベンダーに渡したり戻したりすることです。これには 2 つの方法があります。翻訳ベンダーが XML ファイルを受け入れ、適切にフォーマットされた XML ファイルを返すかどうかを確認してください。これは、翻訳ファイルのインポートとエクスポートを自動化できるため、本当に最良の方法の 1 つです。別の方法として、ベンダーが許可している場合は、Web サイトを作成して、ベンダーが翻訳を編集できるようにすることもできます。

結局、翻訳に対するあなたの答えは、反復と手作業を必要とする他のプロセスでも同じです。自動化、自動化、自動化。できることはすべて自動化します。このシナリオでは、コピー アンド ペーストは役に立ちません。

于 2009-05-30T21:18:59.170 に答える
5

Pootleは、ウェブ上で翻訳プロセスを管理できるウェブアプリです。

于 2009-05-30T21:12:38.573 に答える
4

アプリケーションを国際化する際に考慮しなければならない重要な問題がいくつかあります。

  • すべての文字列が同じように作成されるわけではありません。言語によっては、文の長さが大幅に変わる可能性があります。一部の言語では、長さが半分になることもあれば、3 倍になることもあります。英語の文字列よりも大きい文字列を処理するのに十分なスペースを確保して、GUI ウィジェットを設計してください。
  • 通常、翻訳者はプログラマーではありません。翻訳者がリソース ファイルの正しいファイル形式を読み取って維持できるとは思わないでください。変換されたデータ ラウンド トリップをスプレッドシートなどからリソース ファイルに変換できるメカニズムをセットアップする必要があります。1 つの可能性は、Open Office で XSL フィルターを使用して、スプレッドシート アプリケーションで直接リソース ファイルに保存できるようにすることです。また、翻訳者や翻訳サービス会社はすでに独自のデータベースを持っている可能性があるため、彼らが何を使用しているかを尋ね、自動化するためのツールを作成することをお勧めします。
  • 文字列にデータを追加する必要があります- 必要がない、またはいつでも最後に文字列を追加できるというふりをしないでください。文字列のプレースホルダーを置き換えるための文字列フォーマッターが設定されていることを確認してください。さらに、翻訳者のために置き換えられる一般的な値を必ず文書化してください。プレースホルダーの順序は、言語によって異なる場合があることに注意してください。
  • i8n 文字列変数に、その意味を反映した名前を付けます。特定の文字列の内容を確認するために、リソース ファイル内の数値を検索する必要がありますか。開発者は、コード内の文字列出力を読み取って効率化できることに、自分たちが思っている以上に大きく依存しています。
  • コード生成を恐れないでください。私の現在のプロジェクトでは、ant によって呼び出される小さな Java プログラムを作成しました。このプログラムは、既定の言語 (マスター) リソース ファイルのすべてのキーを解析し、そのキーをローカリゼーション クラスで定義された定数にマップします。下記参照。//---- コメント間の行は自動生成されます。文字列を追加するたびにジェネレーターを実行します。


public final class l7d {
...normal junk

/** * Reference to the localized strings resource bundle. */ public static final ResourceBundle l7dBundle = ResourceBundle.getBundle(BUNDLE_PATH);

//---- start l7d fields ----\ public static final String ERROR_AuthenticationException; public static final String ERROR_cannot_find_algorithm; public static final String ERROR_invalid_context; ...many more //---- end l7d fields ----\ static {
//---- start setting l7d fields ----\ ERROR_AuthenticationException = l7dBundle.getString("ERROR_AuthenticationException"); ERROR_cannot_find_algorithm = l7dBundle.getString("ERROR_cannot_find_algorithm"); ERROR_invalid_context = l7dBundle.getString("ERROR_invalid_context"); ...many more //---- end setting l7d fields ----\ }

上記のアプローチには、いくつかの利点があります。

  1. 文字列キーがフィールドとして定義されるようになったため、IDE はコード補完をサポートする必要があります。これにより、多くのタイプを節約できます。文字列を印刷するたびに、すべてのキー名を調べてタイプミスを修正するのは本当にイライラします。
  2. 私が間違っている場合は、誰かが私を修正してください。(例のように) 静的なインスタンス化ですべての文字列をメモリにロードすると、追加のメモリ使用量を犠牲にして、ロード時間が短縮されます。使用される追加のメモリ量はごくわずかであり、トレードオフの価値があることがわかりました。
于 2008-11-10T10:13:34.710 に答える
2

私が取り組んだローカライズされたプロジェクトには、「文字列凍結」の日付がありました。この後、文字列の変更が許可された唯一の方法は、プロジェクト管理チームの非常に上級メンバーの許可を得た場合でした。

これは完全な解決策ではありませんが、正当な理由がある場合は、次のリリースまで文字列に関する欠陥を保留にすることができました。文字列のフリーズが発生すると、「その場しのぎの」決定でプロジェクトに真新しい機能を追加することを拒否する正当な理由もあります。そして、許可が上層部から得られるということは、中間管理職があなたの仕様を変更する権限を持たないことを意味していました :)

于 2008-10-10T12:49:18.400 に答える
2

利用可能な場合は、データベースを使用してください。各文字列は id を取得し、各言語のテーブル、または列に言語を含むすべてのテーブルがあります (サイトへのアクセス方法に応じて、どちらが優れているかがパフォーマンスによって決まります)。これにより、コード ファイルやバージョン管理の詳細を管理しようとすることなく、翻訳者からの更新が可能になります。さらに、翻訳されていないものについてレポートを実行し、自動翻訳 (エンジン) と実際の人間による翻訳とを追跡することはほとんど簡単です。

データベースがない場合は、バージョン管理の問題が軽減されるように、各言語を個別のファイルに貼り付けます。ただし、構造は基本的に同じです。各文字列には ID があります。

-アダム

于 2008-10-10T12:51:44.900 に答える
2

自慢のリソース ファイルの代わりにデータベースを使用しただけでなく (データベースを扱うための優れたツールがあるのに、なぜ人々がそのようなものを使用するのか理解できませんでした)。リフレクションを使用して変換用のコントロールを識別することにより、アプリケーション内のものにタグを付けます (VB6 フォームでコントロールに数字のタグを付けるのを忘れることは常に問題でした)。次に、コントロールを辞書データベースのフレーズ ID に変換する XML ファイルを使用します。

マッピング ファイルは管理する必要がありましたが、ビルド プロセスとは別に管理することができ、アプリケーションの変換は、データベースで権限を持つエンド ユーザーによって実際に可能でした。

于 2008-10-10T12:58:10.817 に答える
1

ここまでにたどり着いた解決策は、すべてのプロパティ ファイルを読み取り、すべての翻訳 (言語をヘッダー、キーを行) と共にマトリックスを表示する小さなアプリケーションを Excel に作成することです。何が欠けているかは明らかです。これは翻訳者に送信されます。戻ってくると、シートを処理して同じプロパティ バンドルを再び生成することができます。今のところ痛みは少し和らぎましたが、他に何があるかと思います。

于 2008-10-10T12:54:30.887 に答える
1

すべての .properties ファイルを検索する makefile ターゲットを配置し、それらを zip ファイルに入れて翻訳者に送信します。私は差分だけを送信することを提案しましたが、何らかの理由で毎回ファイルのバンドル全体が必要です。彼らは違いだけを追跡するための独自のシステムを持っていると思います。なぜなら、ある時点から次の時点で変更された文字列の数に基づいて料金が請求されるからです。配達が戻ってきたら、以前の配達とすべてのファイルを手動で比較して、予期しない変更があったかどうかを確認します。一度、すべての PT_BR (ブラジル ポルトガル語) 文字列が変更され、PT_PT (ポルトガル ポルトガル語) を使用していたことが判明しました。 ) PT_BR の順序に関係なく、そのバッチの翻訳者。

于 2008-10-10T12:56:54.173 に答える
1

この google book - resource file managementは、いくつかの良いヒントを提供します

リソース ファイル管理ソフトウェアを使用して、変更された文字列を追跡し、ワークフローを制御してそれらを翻訳することができます。そうしないと、フリーズと圧倒されるバージョン管理の混乱に陥ります。

この種のことを行ういくつかのツール - 接続なし、実際に使用したことはなく、調査中

http://www.sisulizer.com/

http://www.translationzone.com/en/products/

于 2009-02-07T15:15:32.787 に答える
0

Java では、文字列をリソース バンドルに移動することで国際化が実現されます。翻訳プロセスは依然として長くて骨の折れる作業ですが、少なくともソフトウェアの作成、サービス パックのリリースなどのプロセスからは切り離されています。変更が加えられるたびにすべてを再パッケージ化する CI システム。コードの変更、新しい言語パック、またはその両方であるかどうかにかかわらず、数分で新しいバージョンをテストして公開できます。

于 2008-10-10T12:46:39.310 に答える
0

まず、翻訳が欠落している場合に備えて、デフォルトの文字列を使用します。たとえば、英語またはスペイン語の値です。次に、翻訳者が使用する Web アプリまたは類似のものを検討することをお勧めします。これには事前にいくつかのリソースが必要ですが、少なくともファイルを送信する必要はなく、翻訳者にとってどの文字列が新しいかなどは明らかです.

于 2008-10-28T14:54:35.150 に答える