2012-01-05 8 views
0

私はアラビア語に移行したい大きなアプリケーションを持っています。 resourcestringキーワードの下にユーザーに表示する文字列を定義しました。翻訳されたフォームリソースを持つリソースのみのDLLを作成する

私はDelphi 6で提供されているExternal Translation Managerを使用していますが、私はこのツールを使用するのはあまり快適ではありません。私は、Delphi ETMのやり方のような翻訳されたすべての文字列を含むリソースのみを作成し、実行時にボタンをクリックするだけで言語を切り替えたいと思っています。

私はresourcestringsをDllにリンクすることができましたが、フォームのキャプションとヒントとコンポーネントのプロパティについてはどうでしょうか?言語に応じて実行時にDllをロードしていますが、フォームのプロパティはDllで使用できないため反映されません。

正しい方向のポインタはありますか?

おかげ ラーフルW

+0

Delphi 6を使用していますか?その場合、アラビア語でUnicodeが必要ですか?あなたがそれを見ていない場合はもう一つの方法は[Delphi用のgnugexttext](http://dxgettext.po.dk/) –

+1

@Mike:アラビア語ではUnicodeは必要ありません。アラビア語のANSIコードページと適切なフォントのサポートが利用できます。 Unicodeが許すのは、同じアプリケーションで複数の異なる言語を混在させることです。非西洋言語は、Unicodeが設計されるずっと前にコンピュータによってサポートされていました。 –

答えて

1

何のDelphiローカリゼーションツールとランタイムサポートがやっていることは、リソースの負荷をリダイレクトすることです - フォームを含む - 実行可能ファイルからDLLへ。フォーム、コンポーネント、およびコントロール(デフォルト以外のプロパティ)は、実行時にリソースとして格納されます(実行時に完全に作成しない限り、プロパティを1つずつ設定する必要があります)。

標準翻訳ツールと同じように作業したい場合は、同じ方法で作業する必要があります。 DLLリソースウィザードは、ローカライズできるコピーにすべてのプロジェクト.dfm(および手動で追加したもの)とresourcestringsを抽出します。アプリケーションが起動すると、.dfmがロードされる場所からフォームロードコードがチェックされます。リソースをロードするには、このコードをオーバーライドする必要があります。

リソースからフォーム全体を読み込むと、作成状態に「リセット」する可能性があるため、実行時に言語を変更すると、別の方法が必要になることに注意してください。一方、gettextのようなアプローチと比較すると、イメージや色を含むフォームのテキストよりもはるかに多くをローカライズし、新しい文字列にコントロールのサイズを簡単に適合させることができます。 IMHOのgettextは単純なニーズには適していますが、ローカリゼーションが複雑な作業になり、非常に異なる "文化"をローカライズする必要がある場合は、より強力なツールが必要になります。

+0

+1。テキストコンテンツはローカリゼーションの一部に過ぎません。また、テキストだけでも、言語の冗長性が大きく異なる可能性があるので、デザインに合わせて調整する必要があることがよくあります(テキストの方向に応じてレイアウトに入ることさえありません)。 –

+0

@Idsandon Classesのデルファイコード、System.pasファイルが、私はリソースからフォームをロードしているルーチンを見つけることができませんでした。私はコードにブレークポイントを入れようとしましたが、有効にされなかったブレークポイントはほとんどありませんでした。あなたがリソースからコンポーネントをロードするルーチンを知っていれば、それは私に大きな助けになるでしょう... –

+0

さらに、私がまだ驚いているのは、再実行の代わりに実行時に翻訳を追加することですexesをコンパイルする。私はgnugexttextのソースをチェックして、そのアイデアはexeファイル内に埋め込まれた言語ファイルを使用することです。ファイルシステムに保存することもできますが、アプリケーションのパフォーマンスが低下することはありません。ない?私が間違っている場合は私を正す...私はフレームワークを開発したい。 –

関連する問題