要件を満たす可能性のあるオープンソースのオンライン翻訳ツール(お客様の選択したサーバーに展開可能)は、Translate Toolkitの上に構築されたPootleです。私はLibreCADの翻訳者としてPootleを使用しました。 LibreCAD's Translation Serverを閲覧し、実際にそれを見ることができます。 LibreCADはQtをベースフレームワークとして使用し、PootleはQtの翻訳に使用されるTSファイルのアップロードとダウンロードを処理します。 Transifexも使用していますが、Pootleはそれほど素晴らしいものではないことがわかります(LibreCADの翻訳サーバーは古いバージョンのPootleを使用していますが、あなた自身がそれを見るかもしれませんが)。あなたのアプリケーションが翻訳に必要なファイルは、翻訳サーバーからエクスポートされる(および場合によってはインポートされる)ことができます。 Webブラウザを使用して翻訳することも、オフラインで翻訳してから編集したファイルをアップロードして、変更されたすべての翻訳を一括適用することもできます。 Translate Toolkitにも基づいている一方で、Pootle(よりよく見え、きちんとしたバージョンコントロールの統合を持っている)よりも似ていますが、より現代的なアプローチを提供するもう一つのWebベースの翻訳ツールはWeblateです。これはオープンソースでもあり、あなたの選択したサーバーに展開できます。
より多くの洞察を提供するために、Translation Related File Formatsを見ると、PootleとTranslate Toolkitがエクスポート/インポートできるものをよりよく知ることができます。そのリストと私の翻訳経験から、のコアと拡張子のINIファイルが翻訳に使用され、Yiiアプリケーションの翻訳にPHP翻訳配列が使用されており、前述のようにQt Linguist TSファイルが使用されているQtアプリケーションでの翻訳私はまたGNU gettextで実験しました。これはローカライゼーションのためのFree Software Foundationライブラリによって保証されています。GNU gettextはPOファイルを翻訳に使用します。これはTranslate Toolkitで処理できます。
プラットフォームが何であるかにかかわらず、すべてのローカリゼーションアプローチの背後にあるコアアイデアは、ほぼ同じです。特定のメイン言語を念頭に置いてコードを設計し、コード内でこの言語を使用します。英語は理想的な選択ですが、これは必須ではありません。すべての開発者が作業できる言語、開発のスピードを遅らせることのない言語(ボタンの2つのラベルを探したり、1つのラベルを1分だけ考えることは望まないでしょう)、およびメインのターゲットオーディエンスが存在し、同時に別の言語を念頭に置いて開発した場合にのみ、メインのターゲットオーディエンスによって使用されます視聴者の言語。これは、他のすべてのターゲット言語に翻訳するために、すべての翻訳者がソース言語文字列を受け取る(したがって、参照点として持つ)言語でもあります。あなたが妥協しなければならないのは、開発のための唯一の言語について話しているからです。開発中にコードに言語文字列を挿入する必要がある場合は、コードを直接挿入するのではなく、使用するローカリゼーションプラットフォームで指定された特別な関数呼び出しで囲みます。たとえば、Qtアプリケーションでは、QLabel *label = new QLabel("Password:");
の代わりにQLabel *label = new QLabel(tr("Password:"));
と書きます。アプリケーションの実行中に、ユーザー言語はtr
関数呼び出しの中で決定され、ユーザー言語の適切な言語ファイルがブラウズされ、ユーザー言語の"Password:"
に対応する翻訳メッセージが検索され、ラベルとして使用されます。言語の決定/定義はグローバル/静的変数を本質的に取得/設定する別個のメカニズムであり、上記の例ではtr
関数が呼び出されたときにルックアップされます。各プラットフォームによって特別に処理されるものは複数形(何らかのパラメータに基づく条件付き変換)です。たとえば、Yiiの場合、'n==1#one book|n>1#many books'
を翻訳文字列として使用できます。アプリケーションではYii::t('app', 'n==1#one book|n>1#many books', 1);
を使用します。つまり、正しい形式を使用できるように、実際の数値をパラメータとして指定します(翻訳機能で使用される'app'
パラメータは特定の翻訳カテゴリapp
を参照します。すべての言語で、アプリケーションの一部に異なる翻訳カテゴリを使用できます)。
最終的な洞察力を追加するには、翻訳に一般的な共通のバックエンドを使用すると、翻訳された文字列の大部分を、あるフレームワークから別のフレームワークに移行するとき、または複数の異なる実装が存在する場合でも同じアプリケーションを同時に、例えばブラウザベースのアプリケーションがネイティブアプリケーションとともに存在します。複数のフォームでは、実際にプラットフォーム固有であるため、同じ言語文字列に対して特別な処理と別々の変換が必要です(ただし、必要に応じて、翻訳文字列ドメインからコードドメインに条件を移動することで、しかし、アプリケーションの大部分の翻訳は、ある文字列を別の文字列に直接マッピングすることです。 Qtのようなフレームワークの中には、特別な翻訳機能(Qtのtr
)の新しい使用法に基づいて、ソースファイルをスキャンして翻訳ファイルを更新するためのツールがあります。そのようなツールが選択したフレームワークに存在する場合は、翻訳ファイルに手動で翻訳マッピングを追加する必要はありません。ソースファイルをスキャンした後、マッピングは翻訳ファイルに表示され、翻訳の元の文字列がデフォルトになり、翻訳された文字列が置き換えられるのを待っています。アプローチにコミットする前に、可能なワークフローを調べてください。
現在、同じ問題が発生しています。私は、私たちのものを作ることが最も安く、最高の解決策であるという結論に達し始めています。オンラインのものは、一般的に、私たちのものを作ることに比べて、複数のプロジェクトや複数の言語で非常に高価です。 – Warpzit
@Warpzit私は有用な情報を提供した答えはないと思います。可能であれば、どのプラットフォームを使用するかについての決定について教えてください。 – xnakos
@ xnakos彼らは実際には多かれ少なかれ貴重な情報を提供しましたが、私はちょうど残りの部分から取り除くためにそれらのうちのどれかに十分な仕事があるとは思わない。 AlexVogelが同じように感じるならばDunno :) – Warpzit