2

ローカリゼーション テストの最適化を検討しています。

私たちの QA グループは、リソースからのすべての文字列が完全に X に含まれるようにする特別なモードの提案をしました。私たちはすでに LoadString とその MFC 実装を API で乗っ取っているので、それを行うことは大きなハードルではありません。

私の質問は、フォーマットの問題をどのように解決しますか?

Examples -

CString str ;
str . LoadString ( IDS_MYSTRING ) ;

where IDS_MYSTRING is "Hello World", should return "XXXXX XXXXX"
where IDS_MYSTRING is "Hello\nWorld", should return "XXXXX\nXXXXX"
where IDS_MYSTRING is "Hello%dWorld", should return "XXXXX%dXXXXX"
where IDS_MYSTRING is "Hello%.2fWorld", should return "XXXXX%.2fXXXXX"
where IDS_MYSTRING is "Hello%%World", should return "XXXXX%%XXXXX"

したがって、要約すると、文字列は printf または Format ステートメントで使用された場合に機能し、エスケープ文字を尊重する必要があります。

これは純粋なコードの質問です C++/MFC

CString ConvertStringToXXXX ( const CString& aSource ) 
{
   CString lResult = aSource ;

   // Insert your code here

   return lResult ;
}

.RC ​​ファイルのツールを使用してこれを実行できることはわかっていますが、英語をビルドしてから、次のように実行したいと考えています。

アプリケーション -L10NTEST

4

6 に答える 6

3

このアプローチが、アプリケーション内のフォーマットされた文字列 (またはフォーマット シーケンス) (つまり、XXXX 以外に表示されるすべてのテキスト) を強調表示することである場合、(おそらく正規表現を使用して) エスケープ シーケンスを見つけ、フォーマットされた (置換された) 値の周りにブロック引用符を挿入できます
。いくつかの\nテキスト -> いくつかの[\n]テキスト

読みやすさが得られ (XXX などのすべての文字列はアプリケーションを使用するのが難しい場合があります)、リソース以外の (ハードコードされた) 文字列も検出できます。

そうは言っても、リソースがロードされていない文字列 (ハードコードされた文字列) を検出したい場合は、X を置き換えるのではなく、文字列の前に付けてください。リソースがロードされた文字列とハードコードされた文字列を簡単に区別できます。
たとえば、Some\ntext -> [EN]Some\ntext

それが役に立てば幸い？

于 2008-10-10T07:01:38.347 に答える
1

appTranslatorの疑似ローカリゼーション機能は、そこで役立ちます。発音区別符号、テキストの拡大または短縮などを使用するように、翻訳されていない文字列を変更します。これまでのところ、あなたは興味がありません。興味深いのは、オプションでそのような文字列を角かっこで囲むことです。アイデアは、文字列が疑似ローカライズされていることをより明確にすることでした。これを使用して、文字列が実際にはコードではなく文字列テーブルからのものであることを検出できます。

そしてもちろん、疑似ローカライズされたプログラムは正しく実行される必要があるため、appTranslatorはすべてのフォーマッター（printfのようなフォーマッターやFormatMessageのようなフォーマッターを含む）と％や\nなどの特殊文字を保持します。それがあなたが探しているものです。

コードを変更する必要はありません。「ダミー」の翻訳を作成するだけです。「ダミー」とは、アプリを翻訳する予定のない言語を意味します。アプリの言語設定をその言語に設定します。待ってください、それはさらに良いです：QAの人はそれを完全に自分で行うことができます。彼らはあなたを煩わせる必要さえありません！:-)

免責事項：私はappTranslatorの作者です。

編集：あなたのコメントへの回答：あなたがすでにappTranslatorを使用していることを読んでうれしいです。L10N DLLにないダイアログまたは文字列による問題を回避するには、DLLを再構築するだけです（たとえば、VSプロジェクトでリンク後の手順を使用します）。このプロセスは、ソースexeを自動的に再スキャンし、ビルドされたリソースdll内の新しいテキストと変更されたテキストをマージします（「ソースの更新」とは対照的に、appTranslatorプロジェクトファイルには影響しません）。これにより、リソースDLLが常にexeと同期していることを確認できます。

于 2008-10-10T10:45:33.513 に答える
0

私の最終的な解決策は、「* [リソースインスタンス名]元の文字列」のように文字列にプレフィックスを付けることでした。それは非常にうまく機能し、たとえばドイツ語には当てはまらない可能性のある文字列を示します。

例：

appres.dll の元の文字列、「My Application」

appres.dll からの新しい文字列、「*[appres]My Application」。

すべての提案をありがとう。

于 2008-10-16T09:57:54.873 に答える
0

ここでコンパイラ理論を適用し、 flex/bison (lex/yacc などのツール)を使用してスキャナとパーサーを生成できます。「Hello」と「World」などの両方に一致する単語として \w+ を定義できます。

于 2008-10-10T06:20:57.667 に答える
0

私は、Microsoft にいたときに疑似ローカリゼーションのために使用したメカニズムを好みます。これには、ローカライズされた各リソースを中かっこで囲むことが含まれていました。リソース => [-リソース-] など。そうすれば、構成された文字列があることをいつでも知ることができ、改行規則を除いて、書式設定は通常変更されません。

通常、文字列の拡張 (元の文字列の周りにさまざまな文字を追加する) と、辞書またはランダム化に基づく文字の置換 ("o" を "ö" に変換する) も行いました。

一部のチームは、リテラル リソース識別子 (名前) をローカライズされたリソースの値として使用することもありました。これは、UI でリソースが実際に使用されている場所を確認できるため、テスターよりもローカライザーにとって有用でした。

于 2008-12-20T05:08:41.603 に答える
0

ソフトウェアがロケールをサポートしている場合、必要なのは XXXX ロケールだと思います。

英語で開発してから XXXX ロケールに切り替えて、すべてが翻訳可能であることを確認します。

于 2008-10-10T08:24:00.117 に答える