🐉 🐅 👆🏾 CMS / CMFでのi18nの実装と汎用化 💎 🤞🏾 🔎

まえがき

自動的にタスクになる緊急の問題に直面しました：
小規模サイトと大規模ポータルの両方のニーズを満たすサイトコンテンツを変換するためのユニバーサルメカニズムを実装する方法

このタスクまたは同様のタスクに遭遇した有能なハブユーザーの意見を聞きたいと思います。

そこで、タスクを設定します。

便利に編集および翻訳できる多言語サイトを実装する必要があります。サイトは、n番目の静的ページで構成されます。言語の数は決まっておらず、おそらく2、おそらく20です。

テーブルのおおよその構造は次のとおりです。

id - ( ) ; title - () ; description - () ; full_text - () .

引数：

ツールがあります-自作のCMFは、管理パネルの自動生成、出力コンテンツの生成（すべてのジェネレーターは基本構造上に構築されます）、およびルーチン作業を容易にするその他の多くの快適なアメニティを生成するようにトレーニングされます。
以下に概説する実装のアイデアがあります。

結果：

サイトコンテンツを翻訳するための便利な管理インターフェイス。
多数の言語の静的ページを備えた簡単なサイト。

アイデアに移りましょう

アイデアの名前については考えませんでしたが、主観的に特徴付けます。したがって、それらを識別します。

1.悪い、明確で一般的に入手可能：
ユニバーサル化を心配せずに、各言語を定義する接尾辞を持つ同じテーブルフィールドに作成します。このようになります：

id title_ru description_ru full_text_ru title_en description_en full_text_en

当然、このオプションには生命権がありますが、2つまたは3つの言語がある場合に限ります。それらがさらにある場合、この構造は非常に不快になります。そして、さらに翻訳可能なフィールドがあれば...
プラスは、ある言語の特定のページにいると、別の言語の同じページに到達することです。編集可能なフィールドの数が多いため、多数の言語の管理は不便です。

2.クリア、修正、正常：
前のものよりも汎用性があります。このテーブルにフィールドを1つだけ追加します。

id title description full_text culture <-

ここで、 cultureは現在のページの言語識別子です。
欠点は、ユーザーが特定のページにいる場合、特定のページのどこに翻訳があるかをサイトが正確に知ることができないことです。多数の言語がある場合、サイトの言語バージョンは完全に異なる場合があります。編集は簡単です。編集する言語を選択し、そこで新しいページの追加を制御します。

3.明確、正確、正常、改善：
前の構造にもう1つのフィールドを追加します。

id title description full_text culture parent_page_id <-

ここで、 parent_page_idは元のページの識別子です。
次に、前の構造が削除されたマイナスがあります。ただし、元の言語への依存関係が追加されます。編集は以前のモデルと同じで、1つの選択が追加され、元の言語の多数のページが追加されます。

4.おもしろい、正しい、しかしもっと複雑な：
ページテーブル構造：

id , ,

テーブルページ_i18nを追加します。

id page_id - page title description full_text culture -

したがって、出力には2つのテーブルの選択を使用する必要があります。
このような構造の編集は難しくありません。翻訳の方向を選択することもできます。特定のページを翻訳できます。翻訳されていないページを見つけます。このサイトにはたくさんのページがあります。

5.面白くてやりがいのあるwiki翻訳：
翻訳エンジンのアイデアはlaunchpad.netから取られています
多くの翻訳者がいる大規模プロジェクトに適しています。

前バージョンと同様。
ページテーブル構造：

id , ,

ページ_i18n_cacheテーブルを追加します。

id page_id - page title description full_text culture - , ,

テーブルi18n_translateを作成します。

id page_id - page field - page_i18n_cache , title translate - user_id - publish - culture - , , , . .

この場合、オリジナルから完全に独立しています。元の言語として任意の言語を選択できます。
「キャッシュ」スキーム、つまり特定のページを選択するには、1つの選択を行い、他のテーブルとマージしないようにする必要があります。キャッシュされたテーブルには、公開された翻訳バージョンのみが含まれます。
翻訳インターフェースはシンプルです。ユーザーには、元の行、他のユーザーが翻訳したバージョンを入力するための行とフィールドが表示されます。

まとめ

私が来た5つのモデルを抽象的に説明しました。インターネットでは、最初の2つのオプションに関する情報のみが見つかりました。
この変換メカニズムを正しく実装する方法についてあなたの意見を聞くのは非常に興味深いです。翻訳インターフェースに関する情報は興味深いものです（特に商用プロジェクトの場合）。

ご清聴ありがとうございました！

CMS / CMFでのi18nの実装と汎用化

まえがき

そこで、タスクを設定します。

アイデアに移りましょう

まとめ

More articles: