14

多言語 PHP Web アプリケーションを開発していますが、gettext で翻訳する必要がある長い (っぽい) テキストがあります。これらは、電子メール テンプレート (通常は短いが数行) とビュー テンプレートの一部 (より長い説明的なテキスト ブロック) です。これらのテキストには、いくつかの単純な HTML が含まれます (強調のための太字/斜体など、おそらくあちこちにリンクがあります)。テンプレートは、出力がキャプチャされる PHP スクリプトです。

問題は、長いテキストを扱うには gettext が非常に扱いにくいように見えることです。一般に、長いテキストは短いテキストよりも時間の経過とともに多くの変更を加えます — msgid を変更し、すべての翻訳でそれを更新するようにします (msgid が長い場合、多くの作業が必要になり、エラーが発生しやすくなる可能性があります)、またはそのままにしておくことができます。 msgid は変更せず、翻訳のみを変更します (これにより、誤解を招く古いテキストがテンプレートに残ります)。また、gettext 文字列に HTML を含めることに対するアドバイスを見てきましたが、それを避けると、テキストの 1 つの自然な断片が多くのチャンクに分割され、翻訳と再構築がさらに大きな悪夢になります。また、反対のアドバイスも見ました。 gettext 文字列を個別の msgid に不必要に分割します。

私が見るもう 1 つのアプローチは、これらの長いテキストに対して gettext を完全に無視し、ロケールごとに外部サブテンプレートでこれらのブロックを分離し、現在のロケール用のものだけを含めることです。欠点は、gettext .po ファイルと完全に別の場所にある個別のテンプレートとの間で翻訳作業を分離していることです。

このアプリケーションは、将来的に他のアプリケーションの出発点として使用されるため、長期的に最適なアプローチを考え出そうとしています. このようなシナリオでのベスト プラクティスについてアドバイスが必要です。同様のケースをどのように実装しましたか？何がうまくいき、何が悪いアイデアになったのでしょうか?

4

3 に答える 3

11

これは、6 つの言語に翻訳された、スタイル設定されたテキスト コンテンツの約数十の長いブロックを含む非常にトラフィックの多いサイトで、私が使用したワークフローです。

  1. テキストベースのマークアップ言語を選択します (ここではMarkdownを使用しました)
  2. 長い文字列の場合は、「About_page_intro_markdown」などの固定メッセージ ID を使用します。
    • テキストの意図を説明する
    • マークダウン形式で解釈されることを明確にします
  3. アプリで「*_markdown」文字列を適切にレンダリングし、少数の安全な HTML タグのみを許可するようにします
  4. 次のような翻訳者向けのツールを構築します。
    • リアルタイムでレンダリングされた Markdown を表示します ( Markdown dingusのようなものです) 。
    • テキストの正式な基本言語の翻訳を簡単に確認できるようにします (これは に含まれていないためmsgid) 。
  5. 新しいワークフローの使い方を翻訳者に教える

このワークフローの利点:

  • メッセージ ID は常に変更されるわけではありません
  • 翻訳者が安全な上位構文で編集しているため、HTML を台無しにしにくい
  • 技術に詳しくない翻訳者は、HTML よりも Markdown の方が非常に簡単に記述できることに気付きました。

このワークフローの短所:

  • 変更されない静的なメッセージ ID を持つということは、テキストの変更を帯域外で送信する必要があることを意味します (長いテキストでは、トーンや強調について疑問が生じる可能性があるため、いずれにせよそうします)。

このワークフローが当社の Web サイトで機能した方法に非常に満足しており、絶対にお勧めし、再度使用します。使い始めるのに数日かかりましたが、ビルド、トレーニング、ローンチは簡単でした。

これがお役に立てば幸いです。プロジェクトの幸運を祈ります。

于 2011-11-15T20:23:19.277 に答える
5

この特定の問題が発生したばかりで、エレガントな方法で解決したと思います。

問題: PHP で Gettext を使用し、主要言語の文字列をキーの翻訳として使用したかった。ただし、HTML の大きなブロック (h1、h2、p、a など) の場合は、次のいずれかを行う必要があります。

  • コンテンツを含む各タグの翻訳を作成します。

また

  • タグ付きのブロック全体を 1 つの翻訳に入れます。

これらのオプションのどちらも私には魅力的ではなかったので、これが私がしたことです：

  • 元のテキストをキーとして、単純な文字列 (「OK」、「追加」、「確認」、「My Awesome App」) を通常の Gettext .po エントリとして保持します。

  • コンテンツ (大きなテキスト ブロック) をマークダウンで記述し、ファイルに保存します。サンプル ファイルは/homepage/content.md(プライマリ / ソース テキスト) /homepage/content.da-DK.md、、、/homepage/content.de-DE.md

  • (現在のロケールの) コンテンツ ファイルを取得して解析するクラスを記述します。私はそれを次のように使用しました：

    <?=Template::getContent("homepage/content")?>

しかし、ダイナミック ラージ テキストはどうでしょうか。単純。テンプレートエンジンを使用します。私はSmartyTemplateに決定し、クラスで使用しました。

マークダウン内でテンプレート ロジックを使用できるようになりました。それはどれほど素晴らしいですか？

それからトリッキーな部分が来ました..

コンテンツの見栄えを良くするために、HTML を別の方法で構造化する必要がある場合があります。その下に 3 つの「機能ボックス」があるキャンペーン エリアを考えてみましょう。簡単な解決策: キャンペーン エリア用のファイルと、3 つのボックスごとに 1 つのファイルを用意します。

しかし、私はそれよりもうまくやることができました。

簡単なブロック パーサーを作成したので、すべてのコンテンツを 1 つのファイルに書き込み、各ブロックを個別にレンダリングしました。

サンプルファイル:

[block campaign]
Buy this now!
=============

Blaaaah... And a smarty tag: {$cool}
[/block]

[block feature 1]
Feature 1
---------

asdasd you get it..
[/block]

[block feature 2] ...

そして、これは私がマークアップでそれらをレンダリングする方法です:

<?php 
// At the top of the document...

// Class handles locale. :)
$template = Template::getContent("homepage/content", [
    "cool" => "Smarty variable! AWESOME!"
]);
?>

...

<title><?=_("My Awesome App")?></title>    

...

<div class="hero">
   <!-- Template data already processed! :) -->
   <?=$template->renderBlock("campaign")?>
</div>
<div class="featurebox">
   <?=$template->renderBlock("feature 1")?>
</div>
<div class="featurebox">
   <?=$template->renderBlock("feature 2")?>
</div>

これは会社のプロジェクトのためだったので、残念ながらソース コードを提供することはできませんが、理解していただければ幸いです。

于 2014-02-20T09:51:47.843 に答える
3

gettext は、大きなテキストを翻訳するために設計されたものではありません。

fwiw 基本的な HTML (strong、a など) を gettext 文字列に含めました。これは、翻訳者が何をしているか (ほぼ正しい) を理解し、翻訳が十分にテストされると確信していたからです。

テキストを段落ごとに 1 つの文字列に分割するアプローチを試しました。テキストの真ん中に英語の段落が1つあると奇妙に見えるのと同じように。これらの文字列の 1 つが変更されたということは、新しいバージョンをリリースする前に翻訳を待たなければならなかったことを意味し、それが私たちの作業を遅らせていました。プラス面としては、翻訳者がテキストのどの部分が変更されたかを簡単に確認できます。このアプローチは、私が試した 1 つのアプリケーションでうまく機能しました。

一部のテキストを外部の場所に分割することもできましたが、1 つまたは 2 つの .po ファイルだけでなく、英語版と手動で比較し、それに応じて更新する必要のある他のテキストが大量にあったため、管理オーバーヘッドが発生しました。これは、翻訳者に、英語版のどこでどのような違いがあったかを説明するメモを提供することを忘れない場合に実行できます.

私はまだどちらのアプローチでも納得していません。

于 2011-11-08T08:13:31.870 に答える