لم أستخدم مترجم مايكروسوفت من قبل، لذا فأنت متقدم علي في هذا الجانب — رغم أنني أشك في أن الطرق ستكون نفسها نظريًا.
أعجبني فكرتك في تحليل فواصل الفقرات، لكنني لست متأكدًا من افتراض أن كل مستند ينتهي سطره بـ CR/LF. فأنظمة 'nix تستخدم حرف LF فقط، بينما تستخدم أنظمة ماك حرف CR فقط، وتستخدم أنظمة ويندوز كليهما. وقد تستخدم مستندات أخرى بايتًا فارغًا كحرف نهاية السطر.
كما أن ترميز Unicode يطرح مشاكله الخاصة، إذ إن كل حرف فيه طوله بايتان.
حل ممكن: فحص فاصل السطر في الجملة الأولى أو الجملتين الأوليين، وحفظه كقيمة، ثم تحويل جميع فواصل الأسطر إلى “\n” فقط قبل تحليل المستند. وبعد إكمال معالجة المستند، يمكن إعادة ضبط فاصل السطر تلقائيًا إلى الصيغة الصحيحة.
إحدى الطرق هي المسح للأمام حتى الوصول إلى 10,000 كلمة، ثم المسح للخلف بحثًا عن فاصل فقرة. ضع مؤشرًا في بداية الكتلة الحالية، ثم المسح للأمام، وعندما تجد آخر فاصل فقرة قبل الوصول إلى 10,000 كلمة، ضع مؤشرًا في النهاية. قم بقص تلك الكتلة، ترجمها، انقلها إلى مستند النتيجة، ثم حرك المؤشر البادئ إلى موقع المؤشر الختامي واستمر.
==============================
كملاحظة جانبية، يمكن أن تكون برامج الترجمة سيئة للغاية، لأن الترجمة غالبًا ما تعتمد بشكل كبير على السياق، أو تحتوي على مصطلحات عامية، أو تستخدم لغة تخصصية. وبالمثل، فإن المصطلحات التقنية أو الكلمات الخاصة بمهارة أو حرفة معينة — التي لا ينبغي ترجمتها في كثير من الحالات — تُشوّه بشكل فظيع. وتُعد المستندات القانونية والطبية والهندسية/التقنية أمثلة كلاسيكية على ذلك.
أرسلت مستندًا طبيًا معقدًا (تقرير العملية الجراحية لإجراء جراحة دماغية لشخص ما) عبر مترجمين مختلفين: Google وYandex، في محاولة لترجمته إلى الروسية. وكانت نتيجة كلا الترجمتين أشبه باللازانيا الفاسدة أكثر من كونها مستندًا مقروءًا!