New Crowdin updates

docs/ar/csharp-differences.md

@@ -0,0 +1,52 @@
+# الاختلافات عن مكتبات C\#
+
+تُعتبر «sil-lift» مشابهة بشكل عام لأدوات LIFT الخاصة بـ SIL المكتوبة بلغة C# — وبشكل أساسي `SIL.Lift` الموجودة في [libpalaso](https://github.com/sillsdev/libpalaso) (المحلل النحوي، أداة التحقق من الصحة، أداة الترحيل، `LiftSorter`)، و`SIL.DictionaryServices` في نفس المستودع (نموذج `LexEntry`/`LexSense`، مع قارئ/كاتب LIFT خاص به، والذي يستخدمه كل من The Combine و WeSay)، ومعالجات LIFT في [Chorus](https://github.com/sillsdev/chorus). إنه تطبيق جديد، وليس نسخة معدلة. تلخص هذه الصفحة النقاط التي يختلف فيها السلوك بشكل متعمد.
+
+## النطاق
+
+| القدرة            | مكتبات C#                                                                              | سيل-ليفت                                                                                |
+| ----------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
+| إصدارات LIFT      | 0.10–0.13 (مع ميزة الترحيل المدمجة) | **0.13 فقط**؛ يتم رفض الإصدارات الأقدم مع ظهور خطأ واضح                 |
+| ترحيل الإصدار     | `Migrator` (سلسلة XSLT)                                             | لا شيء — استخدم ملفات XSLT الموجودة في «lift-standard» لإجراء عمليات الترقية لمرة واحدة |
+| دمج/مزامنة ثلاثية | الكورس                                                                                 | خارج النطاق                                                                             |
+| التحقق من الصحة   | RELAX NG فقط (`Validator`)                                          | RELAX NG + نطاقات المخطط + الفحوصات الدلالية                                            |
+| البث المباشر      | التحليل الداخلي على مستوى العناصر الفردية                                              | واجهة برمجة التطبيقات العامة `open_reader` / `open_writer`                              |
+
+## شكل واجهة برمجة التطبيقات (API)
+
+يعمل محلل `SIL.Lift` على أساس آلية الاستدعاء المرتد (`ILexiconMerger`): فهو يقوم بدفع أحداث التحليل إلى المستلم. بدلاً من ذلك، تُرجع «sil-lift» مخطط كائنات عادي — فئات بيانات مُحددة النوع لكل عنصر من عناصر LIFT — لأن مبرمجي بايثون يفضلون الكائنات، وليس دالات الاستدعاء. تقوم `SIL.DictionaryServices` بتركيب نموذج كائنات `LexEntry`/`LexSense` فوق `SIL.Lift`، ولكنه كنموذج تطبيق لا يمثل سوى البنيات التي تستخدمها تلك التطبيقات — لذا فإن إعادة التسلسل من خلاله لا يمكنها الحفاظ على المحتوى خارج النموذج بالطريقة التي تتبعها معالجة بقايا LIFT ودقة البايت في sil-lift (انظر أدناه). تُنتج واجهة برمجة التطبيقات (API) الخاصة بالتدفق النوع _نفسه_ من `Entry`، لذا لا يوجد نموذج ثانٍ مبسط يتعين تعلمه.
+
+## دقة النقل في كلا الاتجاهين
+
+أقوى اختلاف متعمد. يؤدي الحفظ باستخدام `SIL.Lift` إلى إعادة تسلسل المستند بأكمله. تضمن شركة «سيل-ليفت» ما يلي:
+
+- يتم حفظ المستند الذي لم يطرأ عليه تغيير **بشكل مطابق تمامًا من حيث البايتات**، و
+- تحتفظ الإدخالات التي لم يتم التعديل عليها ببايتات المصدر الدقيقة الخاصة بها حتى عند تغيير الإدخالات الأخرى — وهو نفس أسلوب تقسيم البايتات لكل إدخال الذي يستخدمه «Chorus»، ويتم تطبيقه تلقائيًا.
+
+انظر [ضمانات فيديليتي](fidelity.md).
+
+## التحقق من الصحة
+
+يقوم `Validator` في لغة C# بتنفيذ دورة واحدة من RELAX NG ويُبلغ عن الأخطاء الأولى في شكل سلاسل نصية. يُبلغ sil-lift عن دفق منظم من «المشكلات» (Problem)، يحمل كل منها الملف والمدخل والسطر الذي يتعلق به، وتختلف طبقة مخططه عن قصد في ثلاثة مواضع:
+
+- **عناوين URI غير الصالحة تُعتبر تحذيرات وليست أخطاء.** لم يفرض محرك C# RELAX NG أبدًا نوع البيانات `anyURI`، لذا ظل برنامج FieldWorks (FLEx) لسنوات عديدة يدرج روابط href من النوع `file://C:/...` في المعاجم الفعلية. إن رفض تلك الملفات سيؤدي إلى وضع علامة على كل ملفات التصدير من FLEx تقريبًا.
+- **يتم تطبيق قواعد Schematron** (كعمليات تدقيق دلالية): تم تجاهل لغات النماذج المكررة والقيود المشتركة المماثلة في قواعد LIFT دون إشعار من قبل كل من عملية التحقق من صحة C# وعملية التحقق من صحة lxml الخام.
+- **يتم توحيد المقارنات بين الملفات وفقًا لمعايير يونيكود**، لأن برنامج FLEx يكتب ملف `.lift` بتنسيق NFC، بينما يكتب الملف المصاحب `.lift-ranges` بتنسيق NFD.
+
+يقوم sil-lift أيضًا بالتحقق من صحة الملفات المصاحبة `.lift-ranges` الخاصة بالمعجم الذي تم تحميله، مقارنةً بمخطط خاص بوثائق النطاقات المستقلة (المقدمة من `lift-standard` جنبًا إلى جنب مع قواعد LIFT الأساسية) — يتم فحص كل ملف نطاقات خارجي يتم تتبعه عند كل عملية التحقق من صحة ملف `.lift` — في حين لا يوجد مثل هذا المخطط (أو الفحص) في بيئة C#. (لا توجد نقطة دخول للتحقق من صحة ملف `.lift-ranges` بمفرده، بمعزل عن ملف `.lift`.)
+
+## الترتيب القياسي
+
+تعكس دالة `Lexicon.sort()` القواعد الأساسية لـ `LiftSorter` (المدخلات حسب معرّف فريد (GUID) دون التمييز بين الأحرف الكبيرة والصغيرة؛ النطاقات وعناصر النطاقات حسب المعرّف (ID)؛ تعريفات حقول الرؤوس حسب العلامة (tag)؛ يتم الحفاظ على المعاني حسب ترتيبها في الملف؛ ولا يتم المساس أبدًا بالمسافات البيضاء داخل `<text>`)، مع وجود ثلاثة اختلافات:
+
+- يتم فرز الإدخالات التي لا تحتوي على معرّف فريد (GUID) بشكل حتمي حسب المعرّف (ID) (يفترض `LiftSorter` وجود معرّف فريد (GUID))؛
+- الترتيب مستقل عن الإعدادات المحلية (نقاط الرموز بعد إزالة التمييز بين الأحرف الكبيرة والصغيرة، وليس ترتيب .NET المستقل عن الثقافة)؛
+- تحتفظ القوائم من نفس النوع — مثل الملاحظات والعلاقات والنماذج — بترتيبها في المستند بدلاً من إعادة فرزها حسب المفتاح — فالترتيب في مجموعات أمر حتمي بالفعل، وإعادة ترتيبها لا يؤدي إلا إلى زيادة التشويش في ملفات المقارنة.
+
+لا يتم استخدام ملف `canonicalizeLift.xsl` الموجود في مستودع المواصفات على الإطلاق: فهو يدمج المسافات البيضاء داخل النص اللغوي (عملية تدميرية)، كما أن المعرّفات التي يولدها تختلف في كل عملية تشغيل.
+
+## لم يتم ترحيله
+
+- الميزات الخاصة بـ WeSay (لوحة التحكم/إدارة الإعدادات المتعلقة بملفات LIFT).
+- `SynchronicMerger` (دمج تحديثات Chorus) — فكرة تقسيم البيانات إلى مقاطع بايت لا تزال قائمة في طبقة الدقة، أما عملية الدمج فلم تعد موجودة.
+- تحليل نظام الكتابة LDML: تُعامل الملفات الموجودة في `WritingSystems/` على أنها محتوى مجلد غير شفاف.

docs/ar/fidelity.md

@@ -0,0 +1,33 @@
+# ضمانات فيديليتي
+
+LIFT هو تنسيق _تبادل_، لذا فإن القاعدة الأولى هي **ألا تتجاهل أبدًا ما لا تفهمه**. عقد `sil-lift`، الذي يتم التحقق من صحته بواسطة مجموعة الاختبارات في كل عملية تشغيل (ملفات المجموعة بالإضافة إلى التوليد القائم على الخصائص):
+
+## القراءة
+
+يتم تحميل أي مستند LIFT 0.13 صحيح التكوين — بما في ذلك المحتوى غير المتوافق مع المخطط. كل ما لا يحدده النموذج يتم نقله في حاوية `Extras` غير الشفافة الخاصة بالعقدة الأقرب باعتباره _بقايا LIFT_ — وهو الاسم الذي تستخدمه FieldWorks للإشارة إلى نفس المفهوم، والذي يتم تخزينه في حقل `LiftResidue`: السمات والعناصر غير المعروفة، وتعليقات XML وتعليمات المعالجة، والنصوص المتناثرة، والسمات المكتوبة ذات التنسيق الخاطئ (يُحتفظ بالتاريخ غير الصحيح كسلسلة نصية أصلية في `Extras`؛ ويكون الحقل المكتوب `None`).
+
+## حفظ مستند لم يتم تغييره
+
+تؤدي وظيفة `load()` → `save()` دون إجراء أي تعديلات إلى كتابة **مخرجات متطابقة على مستوى البايت** — دون إعادة تنسيق، أو إعادة ترميز، أو إعادة ترتيب، مع تضمين علامات ترتيب البايت وإعلانات XML. لا توجد حاليًا قائمة تطبيع: الهوية دقيقة.
+
+الاستثناءات (يلجأ الكاتب إلى التسلسل القياسي الكامل، الذي يعتبر كاملاً من الناحية الدلالية ولكنه لا يحافظ على البايتات):
+
+- ترميز المصدر غير متوافق مع ASCII (ليس UTF-8/US-ASCII)، أو
+- يحتوي الملف المصدر على تعريف نوع المستند (DOCTYPE)، أو
+- يختلف كل من الماسح البايت والمحلل حول البنية العليا للوثيقة — على سبيل المثال، وجود `<header>` ثانية خارج المواصفات، والتي يحتفظ بها المحلل مرة واحدة فقط (أما الماسح فهو متحفظ عن عمد: ففي حالة وجود أي شك، لا يلتقط أي بايتات من المصدر على الإطلاق)، أو
+- تم إنشاء المصدر في الذاكرة بدلاً من تحميله من ملف.
+
+## حفظ مستند تم تحريره
+
+- **يتم إخراج الإدخالات التي لم يتم التعديل عليها حرفياً من البايتات الأصلية.** يُعتبر الإدخال قد تم التعديل عليه إذا تغير أي جزء من كائن النموذج الخاص به منذ عملية التحليل (يتم الكشف عن ذلك من خلال لقطة التسلسل القياسي، وليس من خلال علامة التغيير).\*\*
+- **يتم إعادة تسلسل المدخلات التي تم تعديلها بشكل قياسي وكامل**: UTF-8، مسافة بادئة بمقدار مسافتين _خارج_ المحتوى المختلط (لا يتم تغيير المسافات البيضاء داخل `<text>` و`<span>` أبدًا)، وتجميع فرعي موثق لكل عنصر (على سبيل المثال، المدخل: الوحدة اللغوية، الاقتباس، طرق النطق، المتغيرات، المعاني، الملاحظات، العلاقات، أصول الكلمات، التعليقات التوضيحية، السمات، الحقول)، ترتيب ثابت للسمات، التواريخ وفقًا لمعيار ISO-8601 (حرف `Z` لـ UTC). يتم إعادة إصدار جميع البقايا؛ ويتم إعادة وضعها في الفهرس الفرعي الأصلي، مع ربطها بالقائمة الفرعية الجديدة (وهذا تقريب — فالمواضع الدقيقة بالبايت مضمونة فقط للمدخلات التي لم يتم التعديل فيها).
+- تؤدي إضافة العناصر أو حذفها أو إعادة ترتيبها إلى إعادة تسلسل بنية المستند، لكنها تظل تُخرج بايتات كل عنصر لم يتغير حرفياً.
+
+!!! note "&quot;ملف XML القياسي&quot; المذكور هنا لا علاقة له بأي ملف XML قياسي آخر"
+    يُقصد بالصيغة القياسية في هذه الصفحة الشكل الموثق الخاص بـ «sil-lift»، والموصوف في إحدى النقاط أعلاه. ولا علاقة له بعملية «Canonical XML (C14N)» التابعة لـ W3C. ولا علاقة له بفئة `CanonicalXmlSettings` التابعة لـ `SIL.Core`.
+
+## التقريبات المعروفة (العقد التي تم لمسها فقط)
+
+- يتم الاحتفاظ بالتعليقات الموجودة _داخل_ عملية تشغيل `<text>`، لكن يتم نقلها إلى جانب عملية التشغيل، ولا يتم الاحتفاظ بها في موضعها الدقيق من حيث عدد الأحرف.
+- يتم توحيد ترتيب العناصر الفرعية من النوع «المتقاطع» داخل عنصر تم تعديله وفقًا للتجميع القياسي (تجعل خاصية `interleave` في مخطط LIFT هذا الترتيب غير ذي أهمية من الناحية الدلالية).
+- لا يتم إعادة إصدار عنصر متعدد النصوص موجود ولكنه لا يحمل أي شيء — لا نماذج ولا بقايا، على سبيل المثال `<definition></definition>` —. يمثل النموذج هذه الحقول على شكل `Multitext` موجود دائمًا (`lexical-unit`، و`citation`، و`definition`، و`usage` للعلاقة، و`label` / `abbrev` / `description` في مراجع عناوين الويب، والنطاقات، وعناصر النطاق، والعنوان)، لذا لا يمكن التمييز بين النموذج الفارغ والنموذج الغائب بعد التحليل. لا يُفقد أي شيء من الناحية الدلالية.