احسان رضایی

توسعه دهندگان نرم افزار همیشه علاقمند به گسترش فعالیت و رفتن به سمت بازار های جدید هستن. به این معنی که سعی میکنن محصولات خودشون رو در مناطق مختلف قرار بدن. در این مطلب چند روش برای بومی سازی یا مدل سازی داده و طراحی پایگاه داده چند زبانه توضیح داده میشه. مخصوصا بومی سازی در سطح محتوای نرم افزار.

بومی سازی یا محلی سازی به فرآیند تطبیق محصول در بازار های مختلف گفته میشه. این یه موضوع مهم برای دستیابی و فروش در سایر بازار هاست. با این فرآیند کاربران احساس میکنن که یک محصول برای زبان، فرهنگ و نیاز اونها تولید شده.

زمانی که درباره بومی سازی فکر میکنیم در درجه اول ترجمه محتوا ذهن ما رو به خودش مشغول میکنه. ما نیاز به یک مدل پایگاه داده قوی و کارآمد برای ذخیره محتوای ترجمه شده در چندین زبان داریم.

برای درک بیشتر و با توجه به نیاز های مختلف روش های متفاوتی رو بررسی میکنیم. هر کدوم از این روش ها مزایا و معایب خودشون رو دارن. در نتیجه انتخاب بر عهده ی شما و نیازمندی های خاص خودتون هست.

روش اول - اضافه کردن ستون زبان برای هر فیلد.

 ساده ترین روش از نظر توسعه و طراحی. کافیه برای هر زبان داخل جدول یک ستون در نظر بگیرید.

مزایا.

- پیاده سازی ساده.

- هنگام نوشتن SQL Query هیچ پیچیدگی خاصی وجود نداره. مثلا:

Select p.product_name_FR, p.description_FR, p.price, 
       c.name_FR, c.address_FR, c.contact_name 
from order_line o, product p, customer c
    Where o.product_id = p.id and o.customer_id = c.id
    And id = <order number>;

معایب.

- عدم وجود مقیاس پذیری. هر زمان که زبان جدیدی اضافه بشه باید ستونش رو داخل جدول بسازید.

- وقت گیر هست اگر زبان های زیادی در سیستم داشته باشید.

روش دوم - ایجاد جدول جداگانه برای ترجمه(translation table).

در این روش یک جدول جدا برای ترجمه محتوا در نظر میگیریم(جدول translation). که شامل یک ستون به ازای هر زبان هست.

مزایا.

- برای یک مدل داده ی از قبل آماده شده روش خوبی به منظور پیاده سازی هست.

- تغییرات در صورت اضافه شدن زبان جدید به علت یک جدول ترجمه مجزا آسون تر هست.

- میشه متون تکراریُ فقط یک بار ترجمه و سپس از شناسه اون در جداول مختلف استفاده کرد.

معایب.

- اگر یکی از مدل ها فقط یک زبان را پشتیبانی کنه یا یک فیلد تمام زبان ها رو برای ترجمه نیاز نداشته باشه، مشکل مقادیر NULL در جدول زبان به وجود میاد.

- به دلیل JOIN با جدول ترجمه در صورتی که رکورد های زیادی داخل این جدول وجود داشته باشه. SQL Query کند میشه. یه راه حل برای این موضوع جدا کردن جدول ترجمه به ازای هر جدول هست.

روش سوم - یک جدول ترجمه همراه با یک سطر به ازای هر زبان.

شبیه به روش قبلی هست با این تفاوت که زبان ها رو به جای قرار دادن در ستون، به صورت ردیف میبینیم.

مزایا.

- نوشتن SQL Query های مربوط به بازیابی داده ها آسون تر هست.

- نوشتن OEM برای مدل راحت تره.

- هنگام اضافه شدن زبان جدید تغییراتی لازم نداریم. فقط کافیه اطلاعات زبان جدید رو اضافه کنیم.

- بازیابی اطلاعات کاهش پیدا میکنه. مثلا: 

SELECT tp.text,
        p.price,
       tc.text,
        c.contact_name
FROM order_line o, product p, customer c, translation tp, 
     translation tc, language l
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND p.name_translation_id = tp.id
	AND c.name_translation_id = tc.id
             AND tp.language_id = l.id
             AND tc.language_id = l.id
             AND l.name = @in_language
	AND id = <order number>;

معایب.

- باز هم به دلیل یک جدول ترجمه واحد مشکل حجم زیاد این جدول وجود داره. برای حل این مشکل میتونیم جدول ترجمه رو به ازای هر جدول ببینیم. تا حجم اطلاعات این جدول شکسته بشه.

روش چهارم - ایجاد Entity Layer برای فیلد هایی که نیاز به ترجمه دارن و اونهایی که نیاز ندارن.

توی این روش هر جدول تقسیم به دو جدول میشه. یکی شامل فیلد هایی که باید ترجمه بشن و یکی اونهایی که نیازی به ترجمه شدن ندارن. به این ترتیب لایه های جداگانه ای برای هر کدومشون ایجاد میشه.

مزایا.

- عملیات JOIN شکسته میشه. یعنی اگر نیاز به جدول فیلد های ترجمه نباشه هنگام JOIN عملکرد بهتری خواهیم داشت.

- برای بازیابی فیلد های ترجمه به JOIN های کمی نیاز داریم.

- نوشتن راحت تر OEM.

- SQL Ouery های ساده تر برای متون ترجمه.

SELECT pt.product_name, pt.description, p.price
FROM order_line o, product p, product_translation pt, language l
	WHERE o.product_id = p.id AND 
	AND p.id = pt.product_non_trans_id
	AND pt.language_id = l.id
               AND l.name = @in_language
	AND id = <order number>;

- یک روش استاندارد برای چند زبانگی بین موجودیت هاست.

منبع.