ローカライズ文字列リソースを整理する方法は?


14

多くの小さなパッケージで構成される大規模なアプリケーションを開発しています。各パッケージには、ローカライズ用の独自のリソースファイルセットがあります。

ローカライズ文字列を整理して命名するための最良のアプローチは何ですか?

これまでの私の考えは次のとおりです。

重複の処理

同じテキスト(たとえば、「Zip code」)が特定のパッケージ内で複数回出現する場合があります。プログラミング本能(DRY)は、すべてのオカレンスで共有される単一の文字列リソースを作成するように指示します。

繰り返しになりますが、翻訳者は場所によっては長い翻訳( "Postleitzahl")を選択し、スペースの少ない場所では短い翻訳( "PLZ")を選択することもできます。または、一部のオカレンス(「Zip code:」)にコロンを追加し、他のオカレンスには追加しないこともできます。または、場所によっては異なる大文字(「郵便番号」)が必要になる場合があります。これらの引数はすべて、内容が同一であっても、使用ごとに1つのリソースを作成することを指します。

ネーミング

重複を排除することを目的とする場合、contentでリソースに名前を付けることは理にかなっています。おそらくプレフィックスを介した使用の種類を示唆しています。我々が持っているかもしれだからlabelOK= 「OK」をmessageFileTooLarge= 「ファイルは、最大ファイルサイズを超えています。」、およびlabelZipCode= "Zip code"

コンテンツによる命名には、フォーマット引数を自然に処理できるという利点があります。リソースはmessageFileHas_0_MBWhileMaximumIs_1_MB明らかに、実際のファイルサイズと最大ファイルサイズの2つのフォーマット引数を取ります。

ただし、重複を許可する場合、コンテンツだけで名前を付けることは意味がありません。一意のリソース名を取得するには、リソース名に使用場所を何らかの形で含める必要があります。識別子は少し長くなる傾向がありますが、グラフィカルコントロールでは機能します:fileSelectionConfirmationButtonText= "OK"customerDetailsTableColumnZipCode= "Zip Code"。ただし、非ビジュアルコードファイルの場合は難しくなります。最終的に表示される場所がわからない場合、文字列の特定の使用法にどのように名前を付けますか?コードファイルと関数名で?私にはかなり不器用で脆いようです。

全体として、重複を許可しようとしていますが、これをサポートする一貫した命名スキームを見つけるのに苦労しています。

編集:この質問には2つの側面があります。リソースを整理する方法(DRYと複製)、および名前の付け方です。これまでのところ、答えは最初の側面に集中しています。命名規則に関するフィードバックをお願いします!


1
あなたが持っている場合は、小さな LOCセットをそれぞれ持つパッケージを、その後の質問は、あなたは多くの重複を確認するかどうか、発生します。私は重複して行き、コード内の識別子についてあまり心配しません。
マーティンバ

「文字列が最終的にどこに表示されるかわからない場合、文字列の特定の使用法をどのように命名しますか? これは、ロジック(表示する場所を決定する)と表示(実際に表示する)混在するデザインの欠陥の兆候ではないでしょうか。地域データを使用してテキストを作成することは非常に奇妙ですが、移動可能な他の内部データオブジェクトと同様に扱うことができます。
アルファ

回答:


8

特定の文字列が使用されるすべての場合において、意味がまったく同じであると完全に確信できないときはいつでも、複製を受け入れます。

2つのラベルに常に英語(または母国語)の同じ文字列が含まれている場合でも、すべての言語で同じであるとは限りません。複製を受け入れると、このような状況に対処するために必要な柔軟性が得られます(翻訳者ではなく)。

例として、ラベル「Condition」を考えてみましょう。これは、文脈に応じて、ドイツ語で「Zustand」または「Bedingung」に翻訳される可能性があります(他の多くの可能な翻訳の中で)。



2

いくつかの重複を受け入れます。

追加のコントロールを作成することにより、複数の翻訳を回避できます。たとえば、既にテキストが含まれてCancelButtonいるa とan OKButtonで、Cancel / Abbrechen OK / OKは一度だけ翻訳する必要があります。しかし、それはほとんど特別な場合です。


2

これは私達の会社でそれを処理する方法です:

命名規則: ラベルにクラス/セクション/フォーム/などのプレフィックスを付けて名前を付けます。たとえばloadFile_loadButtonloadFile_fileNameLabelloadFile_cancel読み込みファイルの対話に属するすべてのラベルです。この下線付きの命名規則は最も一般的ではありませんが、読みやすさと「グループ化可能性」が向上するため、より標準的な規則よりも優先します。ラベルと比較して、ラベルがどの要素に属し、という名前loadFileLoadButtonloadFileNameLabelおよびloadFileCancel。違いはそれほど大きくないと思うかもしれませんが、数千のラベルがある場合、複合効果はそれだけの価値があります。

ヘッダーコメント: ラベル名の接頭辞に加えて、「ヘッダー」コメントもリソースファイルに追加して、ラベルのグループ化を明確に定義します。このように、特定のクラス/セクション/フォームなどに関連する特定のラベルを変更または追加したい人は、特定の要素に関連するすべてのラベルを1つの場所で、1つのヘッダーの下で見つけ、ラベルを簡単に追加または変更することができます他の要素の翻訳を壊さないことを知っている(私見、これはまた、複製を許可する必要がある理由の非常に強力なポイントです)。

「正当化された」複製が望ましい: 上記のように、これらのプラクティスは間違いなくラベルの複製につながりますが、それについて問題はありません(これを取引ツールで処理する方法の詳細)。

他の人が指摘したように、1つの言語の1つのラベルは、表示されるコンテキストに応じて、他の言語の2つ以上の異なる方法で翻訳できます。ラベルを「統一」すると、翻訳者は、見つかったすべてのコンテキストに対応する単一のラベルを作成するのに非常に苦労します。したがって、「正当化された」複製を許可すると、同じコンテキストで同じものを参照しない限り、ローカライズの品質が向上します(これは「正当化された」の意味です)。

取引のツール: 翻訳を可能な限り効率的に行うために、バンドルに存在する同様のラベルを探し、新しいラベルのデフォルト値として翻訳を提供する独自のツールを構築できます。このような既存のサービスを使用します。これは、先ほど述べたようなツールを提供し、新しいラベルの翻訳を簡単にします(新しいラベルの翻訳オプションがデフォルトでいくつかの翻訳オプションを提供するので)。

要約: 正当な複製とラベルを文脈に沿ってグループ化することは、翻訳者が仕事をするのに本当に役立ちます。ビッグタイム。考えてみてください:翻訳者が適切な翻訳を選択するのを支援する上で、コンテキストを持つことは大いに役立ちます。また、「正当化された」複製を許可すると、一部のコンテキストに適合しない翻訳を1つ選択しなければならないという競合がなくなります(ただし、全体としては最適です)。

これがお役に立てば幸いです!


1

過去にこれを行ったとき、完全な文を含むリソースファイルのルートをたどりました。まったく同じ文が何度も繰り返し使用された場合でも、文内の個々の単語のみである場合、それらの単語は複製されます。

リソースファイルに英語のフレーズのリストが含まれ、その後に翻訳が続くフレームワークに関連付けられていました(高速検索のために最後にいくつかのインデックスデータがあります)。

「ZIP Code」のフィールド名や「OK」のボタンなどの小さなデータプロンプトまたはボタンの場合、文字列「ZIP Code」とそれに続く翻訳が保存され、その完全な文字列が必要な場所で使用されます。しかし、(手動で文字列を分割しない限り)文に現れる「ZIPコード」には使用しません。

郵便番号の例を使用すると、それを自分で翻訳して、それを使用するすべての文で置き換えようとすると、非常に悪い翻訳になります。

たとえば、「郵便番号を入力する必要があります」は、「郵便番号を入力する必要がある」と同等のリテラルを別の言語に翻訳する必要がある場合があります。文章を切り詰めた場合、他の言語で必要な単語の反転は得られません。

そのため、英語への悪い翻訳がばかげているように見えます。それを行う人は、文全体ではなく個々の単語を翻訳しただけです。

文章を分割せずに、全体として翻訳することが常に最善であることがわかりました。挿入が必要なデータ用のプレースホルダー(「部品番号@ 1は冗長」など)があり、翻訳者は適切な翻訳のために必要な位置にプレースホルダーを移動できました。

ただし、まったく同じ文、同じデータプロンプト、または同じボタンラベルなどを使用する場所を許可すると、翻訳を共有できることがわかりました。それが問題として出てくることはなく、翻訳者の時間/コストを節約しました。


丁度。これも行います。翻訳中にラベルや文章を分割しようとしないでください。
マーティンバ

1
本当に私の質問に答えていないのではないかと心配しています。私は文章が決して分割されるべきではないことに絶対に同意します。ただし、ほとんどのリソースは文ではなく、単純なラベル(ボタンテキスト、テーブルヘッダー、フォームラベルなど)です。
ダニエルウルフ

その場合、一度保存して再利用します。おそらくあなたが直接やっていることの範囲外の考慮事項は、翻訳者の費用です。実際、世界中の再販業者に資金を提供し、アプリケーション内で翻訳をテストしてもらいました。彼らは間違いなく重複を避けたいと思っていました。
RosieC

私はいくつかの大きなアプリケーションのスペイン語への翻訳を行ってきましたが、適切な翻訳ツールがあれば、重複は問題になりません(望ましいことです)。これを効果的に処理する方法については私の答えをご覧ください。
carlossierra

0

命名についてのあなたの考えは良いです。

目的

  • ローカライズされたテキストの共通ラベル(変数名)を定義します。
  • ラベルは「心のサイズ」にする必要があります。つまり、明確でありながら実用的な短さです。
  • ラベルは、予測可能性と再現率を最大化するために一貫した形式に従う必要があります。

実装

  • よく知られている略語(つまり、msg = message、lbl = label、btn = button、...)を一貫して使用して、認知負荷を軽減します。
  • ツールは、アルファベット順のリストで変数/ラベルを表示するため、関連するラベルをグループ化する場合、人間による検索が最適です。名前を最も一般的なものから最も具体的なものまで階層化します。(つまり、msgFileMissing、msgFileSaved、msgFileDeleted)。
  • 英語は動詞と名詞の順序付けられた言語です。多くの(ほとんど?)他の言語は名詞動詞です。名詞動詞は、階層的なグループ化に最適です。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.