کثیر لسانی درخواست کا نفاذ

آج ہم کثیر لسانی پر بات کریں گے۔ تو یہ کیا ہے؟

کثیر لسانیات، دوسرے لفظوں میں، بین الاقوامی کاری ، ایک ایسی ایپلی کیشن تیار کرنے کا حصہ ہے جسے پروگرام کی منطق کو تبدیل کیے بغیر کئی زبانوں کے لیے ڈھال لیا جا سکتا ہے۔ صورت حال پر غور کریں: آپ بڑی تعداد میں ممالک کے رہائشیوں کے لیے ایک بڑی تجارتی کمپنی کے لیے ایک ویب ایپلیکیشن بنا رہے ہیں جس میں، مثال کے طور پر، روسی، انگریزی اور ہسپانوی جیسی زبانیں بولی جاتی ہیں۔ آپ کو اسے تمام صارفین کے لیے آسان بنانے کی ضرورت ہے۔ خیال یہ ہے: ایک روسی بولنے والے قاری کو آپ کا ڈیٹا روسی میں دیکھنے کا موقع ملنا چاہیے، ایک امریکی کے لیے انگریزی میں مواد پڑھنا زیادہ آسان ہوگا، اور ایک ہسپانوی کے لیے - ہسپانوی میں (غیر متوقع طور پر، ٹھیک ہے؟) آج کئی بین الاقوامی ماڈلز پر غور کریں ، اور ان میں سے ایک کے لیے (جو مجھے سب سے زیادہ پسند ہے :) آئیے جاوا میں نفاذ کو دیکھتے ہیں۔ ایک گنی پگ کے طور پر آج ہمارے پاس مووی ڈیٹا بورڈ ہوگا۔ آئیے زیادہ خراب نہ ہوں، لہذا ہمارے پاس زیادہ بولنے والے نہیں ہوں گے۔ مثال کے طور پر، یہ ٹھیک ہے۔ اور ہم فلموں کے ناموں کا ترجمہ کریں گے (ہدایتکار - ایکسٹرا کے لیے):

1. ہر زبان کے لیے ترجمہ کے ساتھ جدول

اس ماڈل کا نچوڑ: ڈیٹا بیس میں ہر زبان کی ایک علیحدہ جدول ہوتی ہے، جس میں وہ تمام خلیات ہوتے ہیں جن کو ترجمہ کی ضرورت ہوتی ہے۔ اس طریقہ کار کا نقصان یہ ہے کہ جب بھی ہم کوئی نئی زبان شامل کرتے ہیں، ہمیں ایک نیا ٹیبل شامل کرنا پڑتا ہے۔ یعنی، آئیے تصور کریں کہ ہمارا گاہک بہت اچھا کام کر رہا ہے، اور وہ اپنی درخواست کو دنیا کے بہت سے ممالک (در حقیقت زبانوں) تک پھیلا رہا ہے۔ اس کا مطلب ہے کہ آپ کو فی زبان ایک گولی شامل کرنے کی ضرورت ہوگی۔ نتیجے کے طور پر، ہمارے پاس ایک ڈیٹا بیس ہو گا جو آدھا یا تقریباً مکمل طور پر معاون ترجمے کے جدولوں پر مشتمل ہو گا: خود فلموں کی منصوبہ بندی: ترجمہ کی میزیں:

• روسی
• ہسپانوی
• انگریزی

2. سب کے لیے ایک

ہر جدول میں جو ایک مخصوص ماڈل سے تعلق رکھتا ہے، زبان کی پلیٹ کے لیے شناخت کنندہ کے ساتھ ایک فیلڈ شامل کیا جاتا ہے۔ اس کے مطابق، ڈیٹا بیس میں ترجمہ کے ساتھ یہ جدول بھی موجود ہے۔ مسئلہ یہ ہے کہ ایک شے کئی ترجمے (زبانوں) سے مطابقت رکھتی ہے۔ نتیجے کے طور پر، ہستیوں کی نقل ہو جائے گی، اور یہ منطق کو بہت زیادہ الجھا دیتا ہے اور پیچیدہ کرتا ہے، اور یہ اچھا نہیں ہے۔ ہم یو ایم ایل کو دیکھتے ہیں: ٹیبل فلمیں: ٹیبل زبانیں:

3. کالم فی زبان

جدول میں ہر زبان کے لیے ہر کالم کے لیے علیحدہ ترجمہ کالم بنایا گیا ہے۔ اس نقطہ نظر کا نقصان یہ ہے کہ، ایک بار پھر، اگر زبانوں کی ایک بڑی تعداد کو شامل کیا جائے تو، ڈیٹا بیس کے ڈھانچے کو ہر بار تبدیل کرنے کی ضرورت ہوگی، اور یہ ایک برا طریقہ سمجھا جاتا ہے۔ یہ بھی تصور کریں کہ بین الاقوامیائزیشن کا مطالبہ کرنے والے اشارے کتنے فلا ہو جائیں گے۔ یہ ایک ایسے ماڈل پر غور کرنے کے قابل ہو سکتا ہے جہاں معاون زبانوں کی تعداد پہلے سے معلوم ہو، ان میں سے بہت زیادہ نہیں ہیں، اور ہر ماڈل کو تمام زبان کی مختلف حالتوں میں موجود ہونا چاہیے۔ UML: تمام شامل جدول:

4. بیرونی ترجمہ

یہ اختیار بیرونی ٹولز (گوگل ٹرانسلیٹ، بنگ ٹرانسلیٹ وغیرہ) کو جوڑ کر لاگو کیا جاتا ہے۔ یہ استعمال کیا جاتا ہے اگر آپ کو زیادہ سے زیادہ زائرین کو معلومات فراہم کرنے کی ضرورت ہو، اور اس میں بہت ساری معلومات موجود ہیں۔ اتنے سارے. اس صورت میں، آپ فیصلہ کر سکتے ہیں کہ ڈیٹا بیس میں تمام زبانوں میں معلومات کو براہ راست ذخیرہ نہ کریں، بلکہ اس کا متحرک ترجمہ کریں۔ لیکن یہ یاد رکھنے کے قابل ہے کہ مشینی ترجمہ کا معیار اکثر مطلوبہ بہت کچھ چھوڑ دیتا ہے۔ آپشن کو صرف بہت ہی اقتصادی سمجھا جا سکتا ہے (جب ہر اشاعت کا ترجمہ کرنے کے لیے وسائل نہ ہوں)۔ صحیح ترجمے کے حوالے سے ایک عام مسئلہ یہ ہے کہ جو مترجم زبان اچھی طرح نہیں جانتے وہ کسی لفظ کے غلط معنی کا انتخاب کرتے ہیں اور صارف کو الجھن میں ڈال دیتے ہیں، اور اسے بٹن پر لکھے ہوئے معنی کو آزادانہ طور پر معلوم کرنے پر مجبور کرتے ہیں۔ نہ صرف جملے کا صحیح ترجمہ کرنا بلکہ اس کے معنی کو ایک مخصوص زبان اور قومیت تک پہنچانا بھی ضروری ہے۔ ڈویلپرز کو کچھ زبانوں میں جنس کے ساتھ بہت زیادہ مسائل ہوتے ہیں۔ انہیں صارف کی جنس کے لحاظ سے کوڈ میں فقرے کو نقل کرنا ہوگا، اور اس بات کو بھی مدنظر رکھنا ہوگا کہ نہ صرف اسم کی جنس ہوتی ہے، بلکہ صفتیں اور فعل بھی مختلف طریقے سے متاثر ہوتے ہیں۔ ایسے معاملات ہوتے ہیں جب، درخواست میں انگریزی کے علاوہ کسی دوسری زبان کو منتخب کرنے کے بعد، منتخب زبان کے الفاظ کے ساتھ، اب بھی غیر ترجمہ شدہ عناصر موجود ہوتے ہیں۔ یہ اور بھی برا ہے اگر کئی زبانیں دکھائی جائیں اور یہ ایک قسم کا بابل ہو، جہاں سب کچھ ملایا جاتا ہے اور صارف ایپلیکیشن کو نہیں سمجھ سکتا۔ مثال کے طور پر: https://cloud.google.com/translate/

5. ایپلیکیشن لیول سپورٹ فائلز

ترجمہ کو ذخیرہ کرنے کے لیے الگ فائلیں بنائی جاتی ہیں۔ یہ ایک فائل فی زبان یا ایک فائل فی زبان فی گولی (ٹھیک کرشنگ) ہوسکتی ہے۔ یہ آپشن اکثر اس حقیقت کی وجہ سے استعمال ہوتا ہے کہ ان فائلوں میں بہت سی تحریریں محفوظ کی جا سکتی ہیں، جس کا مطلب ہے کہ میزیں اور ڈیٹا بیس خود پھولا نہیں ہو گا۔ ایک اور سہولت یہ ہے کہ آپ کو ان فیلڈز کے لیے ڈیٹا بیس پر دستک دینے کی ضرورت نہیں ہے، اور کوڈ میں موجود فائلوں کو مطلوبہ زبان کے لحاظ سے متحرک طور پر تبدیل کیا جا سکتا ہے۔ نتیجے کے طور پر، فائل ہمارے لیے ایک لغت کا کام کرتی ہے، جس میں کلید زبان ہے، قدر متن ہے۔ لیکن ہم ذیل میں ".properties" فارمیٹ تک محدود نہیں ہیں، اور یہ فائل فارمیٹس وسیع پیمانے پر مختلف ہو سکتے ہیں - JSON، XML، وغیرہ۔ نقصانات یہ ہیں کہ اس صورت میں ڈیٹا بیس کی نارملائزیشن بہت کم ہو جاتی ہے۔ اس کے علاوہ، ڈیٹا کی سالمیت اب صرف ڈیٹا بیس پر نہیں بلکہ سیریلائزیشن میکانزم پر بھی منحصر ہے۔ اس موضوع پر بہترین مضمون ترجمے کے ساتھ لغت کی فائلوں کی مثال:

• انگریزی
• روسی
• ہسپانوی

6. ہر میز کے لیے معاون ترجمہ کی میز

میری رائے میں، سب سے زیادہ لچکدار حل. اس نقطہ نظر کا نچوڑ زبانوں کے لیے ایک علیحدہ جدول بنانا ہے۔ جب زیر بحث ٹیبل کے لیے ترجمے کے امکان کو لاگو کرنا ضروری ہوتا ہے، تو لینگویج ٹیبل کے ساتھ ایک لنک بنایا جاتا ہے، اور لنک ٹیبل میں زبان کی شناخت، عنصر کی شناخت اور ترجمے کے ساتھ کالم ہوتے ہیں۔ یہ اتنا خوفناک نہیں ہے جتنا یہ لگتا ہے۔ یہ نقطہ نظر معاون زبانوں کی کافی لچکدار توسیع پذیری کی اجازت دیتا ہے۔ آئیے قریب سے دیکھیں۔ یو ایم ایل: فلموں کے ساتھ ٹیبل: زبانوں کا جدول: ترجمے کا جدول: اور جیسا کہ میں نے اوپر کہا، آئیے جاوا کوڈ میں ایک آپشن کے نفاذ کو دیکھیں (جیسا کہ آپ سمجھتے ہیں، یہ آخری آپشن ہوگا)۔ خود ایپلی کیشن میں ایسا کچھ نہیں ہے: ہم کنٹرولرز سے ڈاؤ لیئرز تک جائیں گے۔ ہم تخلیق کا طریقہ دیکھیں گے - مثال کے طور پر یہ کافی ہوگا۔ تو چلیں)) ہمارا جوہر ایک فلم ہے:

@Builder
@Getter
public class Movie {

   private Long id;

   private String producer;
}

کچھ بھی دلچسپ نہیں، صرف پہلی میز کے ماڈل کو نافذ کرنا۔ ڈی ٹی او (ڈیٹا ٹرانسفر آبجیکٹ) کنورٹرز والا کنٹرولر:

@RestController
@RequiredArgsConstructor
@RequestMapping(path = "/cities")
public class MovieController {

   private final MovieService movieService;

   @PostMapping
   public ResponseEntity<moviedto> create(MovieDTO movieDTO) {
       return new ResponseEntity<>(toDTO(movieService.create(fromDTO(movieDTO), movieDTO.getNameTranslations()), movieDTO.getNameTranslations()), HttpStatus.CREATED);
   }

   private Movie fromDTO(MovieDTO dto) {
       return Movie.builder()
               .id(dto.getId())
               .producer(dto.getProducer())
               .build();
   }

   private MovieDTO toDTO(Movie movie, Map<string, string=""> nameTranslation) {
       return MovieDTO.builder()
               .id(movie.getId())
               .producer(movie.getProducer())
               .nameTranslations(nameTranslation)
               .build();
   }
}

ڈی ٹی او میں ہم ترجمے کو نقشے کے طور پر پاس کرتے ہیں، کلید زبان کا مخفف ہے، قدر ترجمے کی قدر ہے (فلم کا نام)۔ DTO:

@Builder
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class MovieDTO {

   @JsonProperty("id")
   private Long id;

   @JsonProperty("name")
   private String producer;

   @JsonProperty("nameTranslations")
   private Map<String, String> nameTranslations;//example = "{'en': 'The Matrix', 'ru' : 'Матрица'}"
}

یہاں ہم خود dto کلاس دیکھتے ہیں، جیسا کہ اوپر لکھا گیا ہے، ترجمے کے لیے نقشہ، باقی فیلڈز مووی ماڈل کا ڈسپلے ہیں۔ آئیے مووی سروس کی طرف چلتے ہیں:

public interface MovieService {

   Movie create(Movie movie, Map nameList);
}

اس کا نفاذ:

@Service
@RequiredArgsConstructor
public class MovieServiceImpl implements MovieService {

   private final MovieDAO movieDAO;
   private LanguageService languageService;

   @Override
   public Movie create(Movie movie, Map<string, string=""> nameList) {
       movieDAO.create(movie);
       Map<Long, String> map = new HashMap<>();
       nameList.forEach((x, y) -> map.put(languageService.getIdByLangCode(x), y));
       movieDAO.createTranslator(movie.getId(), map);
       return movie;
   }
}

یہاں ہم زبان کی شناخت کو اس کے مخفف سے بازیافت کرنے کے لیے نسبتاً تیسری پارٹی کی زبان کی خدمت کا استعمال دیکھتے ہیں۔ اور اس شناخت کنندہ کے ساتھ ہم اپنے ترجمے (ایک نقشے کی شکل میں بھی) کنکشن ٹیبل میں محفوظ کر لیتے ہیں۔ آئیے ڈی اے او کو دیکھتے ہیں:

public interface MovieDAO {

   void create(Movie movie);

   void createTranslator(Long movieId, Map<Long,String> nameTranslations);
}

نفاذ:

@RequiredArgsConstructor
@Repository
public class MovieDAOImpl implements MovieDAO {
   private final JdbcTemplate jdbcTemplate;

   private static final String CREATE_MOVIE = "INSERT INTO movies(id, producer) VALUES(?, ?)";

   private static final String CREATE_TRANSLATOR = "INSERT INTO movies_translator(movies_id, language_id, name) VALUES(?, ?, ?)";

   @Override
   public void create(Movie movie) {
       jdbcTemplate.update(CREATE_MOVIE, movie.getId(), movie.getProducer());
   }

   @Override
   public void createTranslator(Long movieId, Map<Long, String> nameTranslations) {
       nameTranslations.forEach((x, y) -> jdbcTemplate.update(CREATE_TRANSLATOR, movieId, x, y));
   }
}

یہاں ہم اس کے لیے جوہر اور زبانوں کا تحفظ دیکھتے ہیں (لغت)۔ اور ہاں، Spring JDBC یہاں استعمال کیا گیا ہے: میں اسے ابتدائیوں کے لیے بہتر سمجھتا ہوں، کیونکہ یہ زیادہ شفاف ہے۔ آئیے ایک "تھرڈ پارٹی" سروس کی طرف چلتے ہیں۔ زبان کی خدمت:

public interface LanguageService {

   Long getIdByLangCode(String lang);
}

نفاذ:

@Service
@RequiredArgsConstructor
public class LanguageServiceImpl implements LanguageService {
   private final LanguageDAO languageDAO;

   @Override
   public Long getIdByLangCode(String lang) {
       return languageDAO.getIdByLangCode(lang);
   }
}

کچھ خاص نہیں، مختصر نام سے تلاش کریں۔ ڈی اے او:

public interface LanguageDAO {

   Long getIdByLangCode(String lang);
}

نفاذ:

@RequiredArgsConstructor
@Repository
public class LanguageDAOImpl implements LanguageDAO {
   private final JdbcTemplate jdbcTemplate;

   private static final String FIND_ID_BY_LANG_CODE = "SELECT id FROM languages WHERE lang_code = ?";

   @Override
   public Long getIdByLangCode(String lang) {
       return jdbcTemplate.queryForObject(FIND_ID_BY_LANG_CODE, Long.class, lang);
   }
}

ساخت: اوپر بیان کردہ تمام ماڈلز کو زندگی کا حق حاصل ہے۔ آپ کو صورتحال کی بنیاد پر فیصلہ کرنے کی ضرورت ہے کہ کون سا استعمال کرنا ہے۔ بلاشبہ، یہ سب کچھ نہیں ہے: بہت سے مختلف طریقے ہیں، بشمول مختلف زبانوں کے لیے مختلف ڈیٹا بیس کا استعمال، کیچز، مختلف فریم ورک، وغیرہ۔ آج میرے لیے بس یہی ہے اور...