ベストプラクティス多言語ウェブサイト
私はこの質問にかなりの数か月間苦労してきましたが、私は以前にすべての可能なオプションを検討する必要があった状況にありませんでした。今は、可能性を知り、自分の個人的な好みを作成して、今後のプロジェクトで使用する時がきたと感じています。 最初に私が探している状況をスケッチしましょう これからずっと使っているコンテンツ管理システムをアップグレード/再開発しようとしています。しかし、私は多言語がこのシステムの大きな改善だと感じています。以前はフレームワークを使用していませんでしたが、次のプロジェクトではLaraval4を使用します。Laravelは、PHPをコーディングするためのよりクリーンな方法の最良の選択のようです。Sidenote: Laraval4 should be no factor in your answer。プラットフォームやフレームワークに依存しない一般的な翻訳方法を探しています。 翻訳すべきもの 私が探しているシステムは、できるだけユーザーフレンドリーである必要があるため、翻訳の管理方法はCMS内にある必要があります。翻訳ファイルやhtml / php解析済みテンプレートを変更するためにFTP接続を開始する必要はないはずです。 さらに、おそらく追加のテーブルを作成する必要なしに、複数のデータベーステーブルを変換する最も簡単な方法を探しています。 何を思いついたの 私はすでに自分で物事を探して、読んで、試しています。私にはいくつかのオプションがあります。しかし、私はまだ自分が本当に求めているもののベストプラクティスの方法に到達したようには感じていません。現在、これは私が思いついたものですが、この方法には副作用もあります。 PHP解析済みテンプレート：テンプレートシステムはPHPで解析する必要があります。このようにして、テンプレートを開いて変更することなく、翻訳されたパラメーターをHTMLに挿入できます。その上、PHPで解析されたテンプレートを使用すると、言語ごとにサブフォルダーを作成する代わりに、Webサイト全体に対して1つのテンプレートを使用できます（以前に使用していた）。このターゲットに到達する方法は、Smarty、TemplatePower、Laravel's Blade、またはその他のテンプレートパーサーのいずれかです。私が言ったように、これは書かれた解決策に依存しないはずです。 データベース駆動：おそらく私はこれについて再度言及する必要はありません。しかし、ソリューションはデータベース主導である必要があります。CMSはオブジェクト指向およびMVCを目的としているため、文字列の論理データ構造について考える必要があります。私のテンプレートは構造化されているので：templates / Controller / View.phpこの構造はおそらく最も理にかなっています：Controller.View.parameter。データベーステーブルには、これらのフィールドとvalueフィールドが含まれます。テンプレート内では、次のような並べ替えメソッドを使用できecho __('Controller.View.welcome', array('name', 'Joshua'))、パラメータにはが含まれますWelcome, :name。したがって、結果は次のとおりWelcome, Joshuaです。：nameなどのパラメーターはエディターが理解しやすいので、これはこれを行うための良い方法のようです。 低データベース負荷：もちろん、これらの文字列が移動中にロードされている場合、上記のシステムはデータベース負荷の負荷を引き起こします。したがって、管理環境で編集/保存されるとすぐに言語ファイルを再レンダリングするキャッシュシステムが必要になります。ファイルが生成されるため、適切なファイルシステムレイアウトも必要です。私たちは一緒に行くことができますねlanguages/en_EN/Controller/View.phpかの.ini、どんなスーツあなたが最高。おそらく、.iniは、最終的にはさらに速く解析されます。これにはのデータが含まれているはずformat parameter=value; です。レンダリングされる各ビューには、独自の言語ファイルが存在する場合はそれを含めることができるため、これがこれを行うための最良の方法だと思います。次に、言語パラメーターをグローバルスコープではなく特定のビューにロードして、パラメーターが互いに上書きされないようにする必要があります。 データベーステーブルの翻訳：これは実際、私が最も心配していることです。ニュース/ページ/その他の翻訳を作成する方法を探しています。できるだけ早く。モジュールごとに2つのテーブル（たとえばNewsおよびNews_translations）を使用することもできますが、優れたシステムを実現するために多くの作業を行うように感じます。私はに基づいていて思いついたことのひとつdata versioning、私が書いたシステムは：1人のデータベーステーブル名がありTranslations、このテーブルはのユニークな組み合わせを持っているlanguage、tablenameとprimarykey。たとえば、en_En / News / 1（ID = 1の英語版のニュースアイテムを参照）。ただし、この方法には2つの大きな欠点があります。まず、このテーブルはデータベースに大量のデータがあるとかなり長くなる傾向があります。次に、この設定を使用してテーブルを検索するのは大変です。たとえば、アイテムのSEOスラッグを検索することは全文検索であり、かなり馬鹿げています。しかし、その一方で、すべてのテーブルで翻訳可能なコンテンツを非常に高速に作成する簡単な方法ですが、このプロが短所を強調しすぎているとは思いません。 フロントエンドの作業：また、フロントエンドについても検討する必要があります。もちろん、利用可能な言語をデータベースに保存し、必要な言語を（非）アクティブにします。このように、スクリプトはドロップダウンを生成して言語を選択でき、バックエンドはCMSを使用してどの翻訳を実行できるかを自動的に決定できます。ビューの言語ファイルを取得するとき、またはWebサイトのコンテンツアイテムの適切な翻訳を取得するときに、選択した言語（en_ENなど）が使用されます。 それで、彼らはそこにいます。これまでの私の考え。日付などのローカリゼーションオプションはまだ含まれていませんが、私のサーバーはPHP5.3.2 +をサポートしているため、http：//devzone.zend.com/1500/internationalization-inで説明されているように、intl拡張機能を使用することをお勧めします。-php-53 / -しかし、これはその後の開発スタジアムで使用されます。現時点では、主な問題は、Webサイトのコンテンツの翻訳のベストプラクティスをどのように行うかです。 ここで説明したすべてのことに加えて、まだ決めていないことがまだあります。簡単な質問のように見えますが、実際には頭痛の種となっています。 URL変換？これをするべきかどうか？そしてどのように？ つまり、このURLがある場合http://www.domain.com/about-us、英語がデフォルトの言語です。http://www.domain.com/over-ons言語としてオランダ語を選択した場合、このURLを翻訳する必要がありますか？または、簡単な道を進み、に表示されているページのコンテンツを変更するだけ/aboutです。最後のものは、同じURLの複数のバージョンを生成するため、有効なオプションではないように思われます。このコンテンツのインデックス作成は、正しく失敗します。 別のオプションはhttp://www.domain.com/nl/about-us代わりに使用しています。これにより、少なくともコンテンツごとに一意のURLが生成されます。また、別の言語に移動するのも簡単です。たとえばhttp://www.domain.com/en/about-us、提供されるURLは、Googleと人間の両方の訪問者にとって理解しやすくなります。このオプションを使用して、デフォルトの言語をどのように処理しますか？デフォルトの言語で、デフォルトで選択されている言語を削除する必要がありますか？リダイレクトようhttp://www.domain.com/en/about-usにhttp://www.domain.com/about-usCMSが一つだけの言語用のセットアップのときURLで、この言語識別を持ってする必要がないので、私の目には...これは、最適なソリューションです。 …