現在、複数のプラットフォーム（iOS、Android、HTML5、BlackBerryなど）用のアプリケーションの翻訳を作成してホストする際に問題が発生しています。翻訳をホストし、必要な翻訳ファイル（en.lproj/Localizable.string、values-fr/strings.xml、...）をオンザフライで作成するためのベストプラクティスはありますか？複数のプラットフォーム用の翻訳ファイルを作成するためのベストプラクティス
Google Docs（または他のプラットフォーム）のテーブルで翻訳とそのキーをホストし、データをcsvにエクスポートし、スクリプトを使用してファイルを作成することを考えます。
私はインターネットを検索しましたが、これまでのところ良い出発点が見つかりませんでした。
http://www.getlocalization.com/
は、あなたが公にあなたの個々の文字列とその翻訳を投稿し、共有するために喜んでいる場合、それは無料ですがあります。
Heheはい無料ですが、実際には非常に高価です... – Warpzit
はい、彼らは2013年からライセンスを変更しましたので、私はもはやそのプラットフォームを推奨しません。それは、自分のサイトに無料で翻訳を投稿したすべての人々にとって私には悲しいことです。これ以上行う理由はありません。 –
英語と日本語の両方でアプリを作成します。私がやることは、アプリケーションのどこにでもアクセスできるファイル、つまりグローバル変数、インスタンス、シングルトン、またはこれまでに快適に感じたことのあるファイルに両方の翻訳を保存することです。
コンピュータ翻訳者が正しいことを言っていないので、あなたが必要とするすべての翻訳を家に入れてください。 次に、英語や日本語のブール値に基づいてリストからプルを使用します。
これは非常に悪いアプローチであり、異なるプラットフォームの利点を使用しません。 – Warpzit
あなたの上司がああああ、今あなたのiOS版をビルドしていると言ってもうまくいきます。また、なぜ共有インスタンスを悪い方法で使用していますか？それはうまく動作し、あなたは1つの場所でそれを変更することができますし、whoプログラムのために変更されます。それを維持するのは簡単ですが、翻訳エラーがあります。だから、どうやってそれが悪いのか教えてください。 – MNM
この方法では、1つのアプリで2つ以上の言語を使用することができます。また、このアプローチでは、異なる言語間で切り替えることができます。シンプルな方法とオプション画面を用意して、好きな言語をユーザーに尋ねるだけです。 – MNM
要件を満たす可能性のあるオープンソースのオンライン翻訳ツール（お客様の選択したサーバーに展開可能）は、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）の新しい使用法に基づいて、ソースファイルをスキャンして翻訳ファイルを更新するためのツールがあります。そのようなツールが選択したフレームワークに存在する場合は、翻訳ファイルに手動で翻訳マッピングを追加する必要はありません。ソースファイルをスキャンした後、マッピングは翻訳ファイルに表示され、翻訳の元の文字列がデフォルトになり、翻訳された文字列が置き換えられるのを待っています。アプローチにコミットする前に、可能なワークフローを調べてください。
PhraseAppを複数のプラットフォームで使用することに成功しました。彼らはAPIを持っているので、迅速なコマンドで翻訳を更新するためにプロジェクトツリーにシェルスクリプトを提供することができます。あなたはビルドステップとしてそれを行うかもしれません。
異なるローカライズされたプラットフォームには異なる機能セットがあるため、これらのサービスには管理が難しいハードルがあるように思えます。たとえば、AndroidはiOSがIIRCではない複数化をサポートしています。
現在、同じ問題が発生しています。私は、私たちのものを作ることが最も安く、最高の解決策であるという結論に達し始めています。オンラインのものは、一般的に、私たちのものを作ることに比べて、複数のプロジェクトや複数の言語で非常に高価です。 – Warpzit
@Warpzit私は有用な情報を提供した答えはないと思います。可能であれば、どのプラットフォームを使用するかについての決定について教えてください。 – xnakos
@ xnakos彼らは実際には多かれ少なかれ貴重な情報を提供しましたが、私はちょうど残りの部分から取り除くためにそれらのうちのどれかに十分な仕事があるとは思わない。 AlexVogelが同じように感じるならばDunno :) – Warpzit