أود أن أرى القدرة على عمل روابط ديناميكية في وضع aot. هناك حالتا استخدام على وجه الخصوص لدعم سبب إضافة ذلك إلى خارطة الطريق.

الأول هو حالة الاستخدام الأساسية حيث لا تريد تطبيقات منفصلة لكل لغة. يتطلب هذا نوعًا من منطق إعادة التوجيه خارج التطبيق ولا يسمح بتغيير ديناميكي للغة دون إعادة تحميل كاملة للموقع.

والثاني هو الحالة التي تقوم فيها بتضمين التطبيق في الهاتف المحمول باستخدام كوردوفا. بقدر ما أعرف ، فإن اختيارك هو التنقل ، وبالتالي إبطاء الموقع ، وإنشاء تطبيق منفصل لكل لغة ، أو تضمين كل لغة في التطبيق (وهو ما يؤدي بالطبع إلى تضخيمه). لا شيء من هذه الخيارات جيدة. يبدو أن Ionic لا تستخدم i18n ، وأتساءل عما إذا كان هذا هو السبب.

@ jlutz777 ، هاتان حالتا استخدام صالحان ، وقد تمت مناقشة هذا الموضوع داخليًا مؤخرًا وأنا أدافع عن ذلك أيضًا. لم يكن ذلك ممكنًا بسهولة نظرًا لكيفية عمل i18n و AoT في Angular ، ولكن قد يكون ذلك في المستقبل بمجرد أن نحصل على عملية التجميع الجديدة لـ AoT في الإصدار الخامس.
سأضيفها إلى خريطة الطريق مرة واحدة / إذا كان لدينا شيء رسمي وملموس حولها.

أنا أعمل على تطبيق Electron + Angular 2 وأحاول الآن إضافة دعم للترجمة للغات متعددة باستخدام ميزة i18n مع Angular. في الواقع ، تم توثيق استخراج سلسلة القوالب وتحويلها إلى تنسيقات ملفات لغة مختلفة بوضوح ، على الرغم من أنني ما زلت غير قادر على توضيح الأمر والبحث عنه كثيرًا:

• هل يمكنني تبديل اللغة ديناميكيًا؟ أو أحتاج إلى إنشاء تطبيق منفصل للغة مختلفة.
• هل يمكنني إدارة / دمج جميع السلاسل في مكان واحد (في شكل زوج مفتاح / قيمة) ، حتى أتمكن من التغيير
  الخيط في مكان واحد ليتم تنفيذه في مكان متعدد؟
• هل يمكنني الوصول إلى الملف المترجم من أي مكان آخر غير النموذج للحصول على سلسلة لغة معينة باستخدامه
  قدمت المفتاح؟ (كما طلبت أعلاه).

سيتم حل النقطتين 2 و 3 باستخدام ميزة "استخدام سلاسل الترجمة خارج النموذج - # 11405".
بالنسبة للنقطة 1 ، انظر الإجابة التي قدمتها لـ @ jlutz777 أعلاه. في الوقت الحالي ، لا يزال يتعين عليك إنشاء التطبيق بلغات متعددة ، أو استخدام JIT الذي يمكنه تحميل الترجمات ديناميكيًا في bootstrap (لا يتم التبديل في وقت التشغيل ، لكنه لا يزال أفضل من الاضطرار إلى تجميعه × مرات).

يجب أن تكون لغة واجهة المستخدم المستخدمة في التطبيق شيئًا لا يتطلب إنشاء إصدارات متعددة من نفس التطبيق. لا ينبغي أن يكون هذا بأي حال من الأحوال مشكلة "مترجم". إذا كان الأمر كذلك فإن المترجم معيب. يجب أن تكون المشكلات هي إنشاء تصميم التطبيق بحيث يمكن تحميل النص من ملف بيانات في وقت التشغيل. يجب أن يتم ذلك باستخدام وحدة / مكتبة يمكن تحميلها واستخدامها مثل أي وحدة أخرى. لا تجعل هذه وظيفة المترجم على الإطلاق.

figuerres إنه شيء سيتغير في المستقبل ، لا وعود حتى الآن ولكننا على دراية بهذه المشكلة ونبحث عن الحلول الممكنة ، واستخدام ملف خارجي هو أحدها

مرحبًا ocombe - يبدو أننا على الأرجح سنستخدم i18n في Angular لتطبيقنا. هل هناك أي ميزات في المستندات تعتقد أنها قد تصبح مهملة أو ستحدث تغييرات عاجلة في الأشهر المقبلة؟ ان اي معلومات موضع تقدير كبير. وشكرًا مرة أخرى على قرص DVD!

ياrjsteinert! سعيد بمعرفة ذلك!
هناك تغيير واحد فقط مخطط له الآن ، وهو الإنشاء التلقائي للمعرفات. ستتغير الطريقة ولن تتطابق المعرفات بعد الآن ، ولكن ستكون هناك أداة ترحيل cli لتحديث ملفات الترجمة الخاصة بك (ومعلمة يمكنك استخدامها للترحيل فقط عندما تكون جاهزًا).

لقد بحثت كثيرًا في Google عن هذا الموضوع اليوم وأتساءل عما إذا كان يمكن أن يكون هناك حل "بسيط" مثل استبدال علامات i18n بمكالمة إلى خدمة بدلاً من الترجمة؟

حاضر:
تم <span i18n>Hello world</span> => إلى <span>Hello world</span>

فكرتي:
يتم <span i18n>Hello world</span> => إلى <span>{{i18nservice.translate('pass-in-the-generated-message-id')}}</span>

بهذه الطريقة يمكن إجراء الترجمة الحقيقية ديناميكيًا في AOT حيث يمكن ملء الخدمة من واجهة برمجة تطبيقات أو ملف وما إلى ذلك ، وحتى تبديل اللغات لن يكون أكثر من i18nservice.setLocale('de-DE') مع تحميل مصدر جديد.
لا يزال استخراج النص باستخدام أداة xi18n يعمل كما كان من قبل ويمكننا الاستفادة من معرفات الرسائل التي تم إنشاؤها على أي حال لاستخدامها كمؤشر لخدمة الترجمة.
سيظل التنفيذ الحالي يعمل بشكل لا تشوبه شائبة حيث يمكن أن تبحث ngc ببساطة عن علامة "--use-i18nservice" وتجميعها كما هو الحال حتى الآن.

إحدى المشكلات التي يمكنني تحديدها حاليًا هي إدخال خدمة i18nservice في كل مكون حيث يجب أن تكون موجودة في سياق المكونات لتكون قابلة للاستدعاء ، ولكن يجب أن يكون ذلك قابلاً للحل بطريقة أو بأخرى.

اي افكار في هذا؟

إنه أحد الأشياء التي نفكر فيها نعم ، لا تزال هناك مشكلة في كيفية التعامل مع كتل التعليمات البرمجية داخل تلك الترجمات عندما لا يكون المترجم متاحًا في وقت التشغيل (AOT). هذا يعني أنه لا يمكننا استخدام المكونات / التوجيهات / الأنابيب الزاوية داخل الترجمات ...

نعم ، لم أفكر في ذلك.
أقوم حاليًا بتطوير POC / حل بديل يتضمن جميع الترجمات إلى HTML في خطوة الإنشاء (حزمة الويب) ، ولفها في حاويات ng مع مفتاح ng.
بالنسبة لسمات i18n ، يتم استخدام توجيه يقوم بتعيينها على العنصر الأصلي.
يتم أيضًا "تقديم" الترجمات نفسها بعد ذلك لاستبدال جميع العناصر النائبة <x id=".. "/> .

إنه قبيح ولكنه يعمل ... لا يمكنني الانتظار حتى يدعمه ng محليًا.
سيتم نشر POC في وقت لاحق من هذا الأسبوع ، ربما يمكن أن يكون مفيدًا لمزيد من التصور الخاص بك.

توصلت إلى "حل" يناسب احتياجاتي حتى يتم التنفيذ.
يعرض المحمل المسبق الآن HTML لجميع اللغات قبل تسليمه إلى المترجم ، ويعمل مثل السحر حتى الآن.

الريبو: https://github.com/actra-development-oss/ng-i18n-aot-loader
NPM: https://www.npmjs.com/package/@actra-development-oss/ng -i18n-aot-loader

من المحتمل أن يكون للمكون سمة تخبر النظام / المترجم أنه يحتاج إلى خدمة.
ثم تأخذ هذه الخدمة وتعرف لغة وإرجاع النص / العلامات المترجمة.
يتم تخزين كل النص المترجم على الخادم كموارد يمكن للخدمة القراءة منها.

إذا لم يكن للمكون السمة ، فلن يكون هناك وقت تشغيل محلي.
إذا كان المكون يحتوي عليه ، فإنه يستدعي الحصول على البيانات المترجمة في وقت التشغيل.
يقوم المترجم ببناء ملفات البيانات وربط الخدمة.

يبدو لي أن هذه طريقة جيدة للتعامل مع الاحتياجات الأكثر شيوعًا لمعظم التطبيقات وعدم مطالبة المواقع بإنشاء نسخ متعددة من نفس التطبيق والاحتفاظ بها.

خطرت لي هذه الفكرة أيضا.
تكمن المشكلة في أن الترجمات يمكن أن تحتوي على روابط وبالتالي ستفتح النظام لحقن الكود عند تحميل ملفات الترجمة من مصادر خارجية.
بالإضافة إلى ذلك ، ستكون هناك حاجة إلى مترجم لحل هذه الارتباطات ديناميكيًا اعتمادًا على الترجمة.

قد يكون الحل الصحيح لـ IMHO هو الطريقة التي نفذت بها كـ POC (انظر التعليق أعلاه) للترجمات المضمنة في وقت الترجمة ، فقط بطريقة أكثر أناقة وتكاملًا.
سيتم التخلص من كلتا المشكلتين المذكورتين أعلاه ، فقط الجانب السلبي الذي يمكنني تخيله هو حجم الحزمة ، وسوف تنمو إلى "حزمة عادية" + (html-size * locales).
يمكن خفض ذلك من خلال ng-switch ing the i18n -tagged html بدلاً من المستند بأكمله ولكن لا تزال هناك مشكلة في i18n-* -tags.

حسنا هذا هو الأمر؛ في بعض الأحيان يكون لديك حدود ....

من وجهة نظر عملية ، قد يكون من الأفضل عدم الحصول على ذلك ، يمكنك الحصول على جزء من النص يمكن تقديمه بلغات متعددة. نهاية القصة.

تحتاج أن يكون لديك قطعة مرتبطة بالبيانات؟ حسنًا ولكن هذا ليس داخل النص المدول ، يجب أن يكون منفصلاً. لا يزال بإمكانك استخدام html و css لتصميم النتيجة وتنسيقها. ولكن لا يمكنك تضمينها أو دمجها بكل طريقة يمكنك التفكير فيها.
مثل ، يمكن أن يكون لعلامة div أو ap عددًا من الامتدادات ، أحدهما يمثل النص وامتدادًا آخر هو تاريخ منضم يكون امتداد النص مرتبطًا بخدمة اللغة المحلية i18n ، ويكون التاريخ مرتبطًا بخدمة تاريخ معينة حيث يكون الامتدادان في علامة الفقرة التي تنسيقاتها.

اجعل الأمر بسيطًا ، واجعله يعمل مع 95٪ من جميع المستخدمين أولاً ثم اكتشف الحالات الجانبية.

لا أرى ذلك كحالة متطرفة ، فالأمر يعمل كالمعتاد.
Angular هو إطار عمل من فئة الأعمال ، لذا سيتطلب الكثير من مستخدمي i18n ، إن لم يكن جميعهم ، عمليات ربط ، أو على الأقل الجمع والتحديد ، داخل النصوص.

<span i18n>Hello, {user.gender, select, m {Mr.}, f {Ms.}} {{user.name}}</span>
كيف يمكنك حل ذلك بسلاسل منفصلة؟
إجابة بسيطة: لا يمكنك ذلك ، حيث لا يمكنك معرفة قواعد اللغة الهدف ، فليس كل لغة تتبع التنسيق "تحية" ، "جنس" ، "اسم".

سيؤدي فصل هذه الأجزاء إلى:

• اقتل السياق ، فلن يحصل المترجم على معنى الجملة الكاملة
• لا يمكن دمج الأجزاء بالترتيب الصحيح بواسطة CSS ، فسيتعين عليك تحديد قواعد لكل ترجمة ، لذلك إما أن يحتاج CSS-guy إلى معرفة اللغات المستهدفة أو يحتاج رجل الترجمة إلى معرفة CSS ، ولا مقبولة.

يعمل Core i18n بشكل زاوية كما هو متوقع ويمكن استخدامه للتطبيقات على مستوى الأعمال ، والشيء الوحيد المفقود على ما يبدو هو التوافق مع AOT ، لذلك لا أفهم وجهة نظرك لماذا يجب استبدال نظام قوي يعمل بشيء ليس نصفه قادر يتطلب العمل عدة مرات لإنجازه.

لدينا اجتماع غدا لإيجاد حل لهذه المشكلة.

ocombe سعيد لسماع هذا ، آمل أن يؤدي هذا إلى بعض الأشياء الجيدة لإصدار مستقبلي من Angular ، هنا في العمل نحن نحب حقًا كيف يعمل معظمها لتلبية احتياجات التطوير لدينا!

ocombe ، هل من الممكن تغيير اللغة دون إعادة ترميز المستند بأكمله؟ أشرح :
أنا في الصفحة المسماة "حول" ولكن عندما أقوم بتغيير اللغة ، تتم إعادة توجيهي إلى صفحة الدخول الرئيسية في طلبي.

أثناء العمل على تطبيق i18n الخاص بي ، صادفت أيضًا "خطأ" معروف أنه لا يمكن حل أوراق الأنماط الخارجية من على سبيل المثال @ angular / material (الموجودة في node_modules) ، وبالتالي فشلت الأداة ng-xi18n .
لقد قمت بتطبيق "تجاهل الملفات المفقودة" -HostContext لأداة الاستخراج ، أيضًا باسم POC ولكن تم إضافته كـ PR # 17845 لربطه بالمستودع الرئيسي.

ocombe كما يبدو أنك نشط جدًا في هذا الموضوع ، هل تمانع في إلقاء نظرة على العلاقات العامة وإبداء الرأي؟

شكرا ، سوف ألقي نظرة على ذلك.

لقد مرت أيام قليلة من البحث عن طريقة لتنفيذ الاستيعاب في المشروع بأكمله بما في ذلك البيانات الديناميكية ، ولكن لم يتم العثور على شيء ملموس. هل يمكنك أن تقترح علي شيئًا آخر على الأقل يساعدني في الوقت الحالي. شكرا لك.

مرحباocombe! هل يمكننا متابعة النقطة التي أثارتها @ jlutz777 (حول الارتباطات الديناميكية ، وبالتالي عدم وجود تطبيق واحد لكل لغة)؟

شكرا جزيلا لعملك!

يعمل vicb عليه الآن ، وسيكون في 5.x (ليس 5.0 ولكن على الأرجح 5.1)

ocombe هل يجب تحديث قائمة المراجعة؟ أستطيع أن أرى بعضًا منهم قد تم دمجه بالفعل في الإصدارات الأحدث. وسيعكس ذلك بشكل أفضل أعمالك الشاقة. 😃

نعم ، فكرة جيدة ، سأقوم بتحديثها
تحرير: محدث

وقت التشغيل i18n (حزمة واحدة لجميع اللغات مع AOT) - [جارٍ العمل عليها]

أين هي القضية ذات الصلة / العلاقات العامة / المناقشة؟

سيكون من الرائع أن يكون لديك واجهة برمجة تطبيقات لتمديد تنسيقات التاريخ المسماة (على سبيل المثال ultraLongDate ) حتى يكون أنبوب التاريخ الأصلي على دراية به ولن تكون هناك حاجة إلى أنبوب التاريخ المخصص.

مجرد فضول حول التقدم المحرز في "Runtime i18n (حزمة واحدة لجميع اللغات مع AOT)."

يمتلك فريقي العديد من التطبيقات الكبيرة بأكثر من 60 لغة. نقوم حاليًا بتشغيل N builds بالتوازي بحيث يكون N هو عدد اللغات. هذا يتطلب موارد كثيرة ، كما يمكنك أن تتخيل ، لا سيما بالنظر إلى أن التطبيقات كبيرة إلى حد ما ويتم نشرها عدة مرات في اليوم في بيئات متعددة.

ما أتمناه هو:

1. بعض الوقت المتوقع لوقت تقريبي في وقت التشغيل i18n
2. التأكيد على أن وقت التشغيل i18n سيقوم ببناء واحد لجميع اللغات
3. ما إذا كانت كل لغة يتم إنتاجها ستكون كسولة قابلة للتحميل أو ستكون في حزمة واحدة ضخمة

chcaru أثناء انتظار ng لتقديم حل "أصلي" ألق نظرة على https://github.com/actra-development-oss/ng-i18n-aot-loader/
إنه يوفر بالضبط ما تطلبه ، بناء AOT واحد مع عدة لغات.

chcaru :
1 / ETA التقريبي هو Angular v6 (يجب أن يكون الإصدار التجريبي الأول بنهاية شهر يناير ، أعتقد ذلك؟ لست متأكدًا) ، والخبر السار هو أن ترجمات الكود يجب أن تتبع بسرعة بعد ترجمات وقت التشغيل نظرًا لأن جميع الأعمال تقريبًا ستنتهي
2 / نعم
3 / يجب فصل الترجمات عن الحزمة ، ستكون قادرًا على التحميل البطيء للترجمة التي تحتاجها قبل التمهيد ، أو مجرد تجميع كل شيء في حزمة واحدة ، ونريد أيضًا دعم ترجمات التحميل البطيء للوحدات النمطية ، ولكن لست متأكدًا من وقتها كن متاحا

ocombe حتى يتم إصدار angularv6 ، فإن الخيار الأكثر جدية لتحميل الترجمات ديناميكيًا و / أو إنشاء تطبيق متعدد اللغات بحزمة واحدة هو ngx-translate.

هل لديك بعض النصائح لمساعدة الأشخاص على بدء استخدام ngx-translate للترحيل بسهولة عند خروج angularv6؟
أي جسر بين كلا التطبيقين؟

ليس في الحقيقة ، الكود مختلف تمامًا ... سنرى متى يأتي الإصدار السادس بهذه الميزات إذا كنت متحمسًا للعمل على أداة ترحيل

مرحبًا ، شكرًا على شفافية الميزات القادمة.

سيكون من المفيد جدًا معرفة إجابات الأسئلة التالية:

1. هل لديك أي فكرة عن مدى اختلاف سير عمل i18n الجديد عن المسار الحالي الموصوف في https://angular.io/guide/i18n ؟

2. هل ستكون السمة i18n و i18n- * على سبيل المثال السمة i18n-title مع معرف مخصص اختياري لا يزال متاحًا في القوالب؟

3. هل ستظل الأوامر التالية تعمل؟

ng serve --aot --locale fr

ng xi18n  --i18nFormat=xlf
ng xi18n  --i18nFormat=xlf2
ng xi18n  --i18nFormat=xmb

1. كيف سيتم دمج وحدات تحويل الرسائل. xlf المستخرجة من النماذج مع تلك المستخدمة في التعليمات البرمجية؟

1. سنجعل تجربة التحديث سلسة قدر الإمكان ، وعلى الأرجح ما نجح من قبل سيظل يعمل على الأقل حتى الإصدار 7.
2. ستبقى سمات i18n كما هي
3. يجب أن يكون الاستخراج هو نفسه أيضًا
4. ربما يكون هذا هو الجزء الوحيد الذي سيتغير ، ولست متأكدًا من كيفية ذلك ، لذا أفضل عدم إخبارك بالأشياء التي قد تتغير ، ولكن سيتم دمج الرسائل في وقت التشغيل عند إنشاء طرق العرض (لذلك بين التمهيد والعرض الذي يظهر على الشاشة)

بعد تعليق Toub ، بالنسبة لهذه الفترة الانتقالية ، سنكون مهتمين بالحصول على تعليقات للنهج التالي (خلط سمة i18n و ngx-translate) الذي نريد تنفيذه. هدفنا هو تقليل التحديثات التي يجب إجراؤها في الكود إلى الحد الأدنى عندما يكون دعم i18n الجديد جاهزًا.

(لاحظ أننا نريد لغات ديناميكية ، أي لا يتم إنشاء تطبيق واحد لكل لغة)

• سنستخدم السمة i18n حتى نتمكن من الاستفادة من أداة الاستخراج الزاوي.
• استنادًا إلى الأداة المستخرجة ، يمكننا تحويل ملفات xliff (أو بتنسيقات أخرى) إلى محتويات بتنسيقات يمكن استخدامها بواسطة ngx-translate (json أو po)
• سنستفيد من السمة translate في العناصر باستخدام i18n one لتطبيق الترجمات (المستخرجة سابقًا)

هذه عينة:

<!-- Without parameters -->
<div i18n="hello-id" translate>HELLO</div>

<!-- With parameters -->
<div i18n="hello-id" translate [translateParams]="{value: 'world'}">HELLO</div>

شكرا لردودكم!

هل يمكنك فتح مشكلة على ngx-translate لذلك؟ أعتقد أن أفضل شيء هو تحديث lib لدعم سمات "i18n" كبديل "للترجمة"

ocombe شكرا على الاقتراح! أضفت للتو مشكلة لهذا على ngx-translate ...

ocombe المشكلة التي يمكنني رؤيتها هي أنه يتم إزالة سمات i18n / i18n-* في وقت التشغيل (https://github.com/angular/angular/issues/11042). هل هناك طريقة للاحتفاظ بها؟

لقد تحققت وما لم أكن مخطئًا ، لا تتم إزالتها إلا إذا كنت تستخدم Angular i18n (مما يعني أنك تقوم بتحميل الترجمات عندما تقوم بالتجميع).

ocombe أفهم ولكني لا أحمل الترجمات لأنني أستخدم Angular CLI وبدأت التطبيق بـ ng serve ...

ocombe ، ستبدأ شركتنا قريبًا قبل بذل جهد لدعم i18n باستخدام إستراتيجية التطبيق المتعدد لكل موقع محدد حاليًا. نخطط أيضًا لتضمين اللغة في عنوان url وتعيين href الأساسي في التطبيق. بمجرد اكتمال ميزة وقت التشغيل i18n ، ما هي التغييرات التي سنحتاج إلى إجرائها باستخدام إستراتيجية لغة url الخاصة بنا؟ هل هناك طريقة أفضل لنا للبدء في تجنب إعادة تصنيع كبيرة بمجرد إصدار وقت التشغيل i18n؟ شكرا لعملك على كل هذا.

⬆️ يجب أن تقول "سيبدأ قريبًا"

يجب أن يظل تطبيق / لغة واحدة يعمل كما هو الآن (مطروحًا منه التغيير الصغير لتحميل ملف اللغة في bootstrap إذا كنت لا تستخدم cli)

هل يمكن لشخص ما أن يستهدفني في الملف الذي تمت إزالة سمات i18n فيه من حزمة durning للنموذج؟

ccocombe

تم تغييره في 4.2.6 (PR https://github.com/angular/angular/issues/17999)

أهلا! لقد كنت أتابع هذا الموضوع لفترة طويلة. رأيت أن أول إصدار تجريبي لـ v6 خرج. لقد قرأت سجل التغيير ولكني لم أر أي شيء متعلق بهذه المسألة طويلة الأمد. أي أخبار على هذا الصعيد؟ أو على الأقل ، هل هناك أي ضمان بأن الواجهة ستكون مشابهة لـ polyfill الخاص بك؟

شكرا لعملكم!

سيكون في أحد الإصدارات التجريبية الأخيرة ، أو ربما RC (أعرف أنني أعرف ...).
ستكون الواجهة مشابهة لـ goog.getMsg من الإغلاق لأن هذا هو ما تستخدمه Google داخليًا لترجمات الكود: https://developer.pubref.org/static/apidoc/global/closure/goog/getMsg.html
لكن ربما نستخدم مغلفًا ، لذلك ربما سيغير الواجهة إلى Angular ، لست متأكدًا بعد.
في polyfill الخاص بي ، أستخدم واجهة مماثلة ، ولكن مع إمكانية تحديد المعرف والوصف والمعنى إذا لزم الأمر ، وأعتقد أننا سنحتاج إلى ذلك بطريقة أو بأخرى (إما عبر المعلمات ، أو عبر مصمم)

شكرا لكل عملك الشاق! نحن نستعد لإعادة كتابة تطبيق 1.x بالكامل بدءًا من أبريل. هل هناك أي شيء يمكننا / ينبغي القيام به للاستعداد لهذه التغييرات؟ الآن نحن نخطط لاستخدام 6.x. شكرا لك مرة أخرى!

ocombe هل تشعر بالفضول عندما تهبط عبارة "تجاهل المسافات البادئة والتابعة"؟

أحتاج إلى تحديث خارطة الطريق لكنها مشوشة بعض الشيء في الوقت الحالي (حتى بالنسبة لي). من الواضح أن هذه الميزة على وجه الخصوص ليست أولوية ، فلا تتوقع منا العمل عليها في أي وقت قريب

ocombe نعم سيكون هذا رائعًا. نحن أيضًا مهتمون جدًا بوقت التشغيل i18n ، باعتباره نقطة الحجب الوحيدة بالنسبة لنا. هل يمكنك تخمين اكتماله في٪؟

شكرا جزيلا لكم على عملكم الشاق!

تضمين التغريدة

من الواضح أن هذه الميزة على وجه الخصوص ليست أولوية ، فلا تتوقع منا العمل عليها في أي وقت قريب

هل يمكنك توضيح الميزة التي تتحدث عنها هنا؟ لا أريد أن أقوم بأي افتراضات.

ofuangka ميزة "تجاهل المسافات البادئة والزائدة" ليست أولوية.
Karamuto صعب التخمين في الوقت الحالي ، نحن نعمل عليه الآن

تضمين التغريدة
هل يمكنك مشاركة الإنجاز الخاص بك حول Runtime i18n (حزمة واحدة لجميع اللغات مع AOT)

الآن قررنا استخدام أدوات xi18n أو استخدام مكتبات الطرف الثالث لمشروع ضخم متعدد اللغات.
نأمل أن نكون قادرين على استخدام الأدوات المتعارف عليها ، ولكن مع إدراك أنها خام للغاية.

كما نود أن نكون قادرين على تقسيم ملفات xlf (ملف واحد لكل وحدة) ، هل هذا ممكن؟

فوق فوق
هل سيتم إصدار وقت التشغيل i18n في Angular 6؟

شكرا وترميز سعيد!

يفقد الأمل هنا ، أن هذا سينتهي في الوقت المناسب ، حيث لم يتبق الكثير من الوقت ولم يكن هناك حركات حتى الآن فيما يتعلق بهذه الميزة.

سيكون إصدار الإصدار 7 متأخرًا جدًا بالنسبة لنا.

Karamuto # 22654
أعتقد أنه سيتم إصداره في الإصدار 6 ، لكن عليهم إنهاء Ivy أولاً.

يجب أن يكون لدينا عالم ترحيب يعمل هذا الأسبوع ، ولكن مع الحد الأدنى من الميزات (لا يوجد دعم وحدة العناية المركزة على سبيل المثال).
ولكن نظرًا لأنه تم إصداره مع Ivy خلف العلم ، فسوف نستمر في العمل عليه وإصداره بمجرد أن ننتهي من ميزة جديدة ، فلا داعي لانتظار الإصدار 7

تضمين التغريدة
هذا يبدو رائعًا! لا يلزم أن تكون كاملة مع وحدة العناية المركزة من البداية. إذا كان سيتقدم في القيم الأخيرة من الإصدار السادس ، فهذا جيد تمامًا من جانبنا.

شكرا على العمل الرائع مرة أخرى!

@ Karamuto انظر # 22654 لقمة التسلل!

سؤال غبي: هل هناك طريقة للحصول على توجيه i18n للمدخلات القائمة على السلسلة إلى المكونات المخصصة. مثال عند إعادة توجيه تسميات aria:

أقوم بلف زر مخصص يقوم بأشياء رائعة:

يقوم قالب الزر المخصص بما يلي:

هل هناك طريقة للقيام بذلك بالفعل؟

kekraft أعتقد أنه مع المدخلات الثابتة ، يمكنك استخدام بناء جملة السمة i18n:

<custom-button ariaLabel="your label" i18n-ariaLabel></custom-button>

في المكون:

<button [attr.aria-label]="ariaLabel">Some button</button>

ocombe هل تحتاج إلى مساهمين لإنجاز أي وقت تشغيل i18n ؟

نعم ! الإصدار 6 تم نشره ~~~
أي تحديث هنا؟

المثال i18n الزاوي 6 هنا
https://github.com/angular/angular/pull/23660

sandangel هل تقصد ببساطة "كل شيء" أو "كل شيء يتم فحصه" ، من الخطط في بداية هذا الموضوع؟
كنت أتطلع حقًا إلى الحصول على تطبيق واحد ، أعتقد أن هذا أحد أهم الأشياء. انتقلت إلى # 23660 الذي قمت بربطه ثم وصلت إلى https://pr23660-e12f469.ngbuilds.io/guide/i18n
ولكن هناك ما زال يقول:

عندما تقوم بالتدويل باستخدام مترجم AOT ، يجب عليك إنشاء حزمة تطبيق منفصلة لكل لغة مسبقًا وتقديم الحزمة المناسبة بناءً على اكتشاف لغة جانب الخادم أو معلمات عنوان url.

هل من الممكن أن يكون لديك تطبيق واحد لعدة لغات أم لا حتى الآن؟

MrCroft يبدو أن وقت التشغيل i18n لا يزال قيد التقدم. قرأتها مثلك بعض المزيد من الخيارات ولكن ليس حزمة واحدة لجميع الترجمة :(

لدينا عالم مرحبًا يعمل ولكنه مخصص للعارض الجديد (Ivy) فقط وبما أن Ivy ليس جاهزًا لوقت الذروة ، فسيتعين عليك انتظار ذلك لسوء الحظ :(

ocombe لذلك ، ما لم يكن لدينا Ivy في الإنتاج (ربما حول الإصدار 7) فلن يكون لدينا ترجمات وقت التشغيل. هل هذا صحيح؟

ocombe هل أهلاً بالعالم وأشياء اللبلاب متاحة للجمهور؟ سيكون من الرائع محاولة فهم تطبيق i18next الجديد هذا

fetis https://github.com/actra-development-oss/ng-i18n-aot-loader/

fetis نعم :(
feloy نعم ، عالم الترحيب البسيط موجود هنا: https://github.com/angular/angular/tree/master/packages/core/test/bundling/hello_world_i18n ولكنه بسيط للغاية
يمكنك العثور على الاختبارات هنا: https://github.com/angular/angular/blob/master/packages/compiler/test/render3/r3_view_compiler_i18n_spec.ts
وبعض إعادة البناء + الاستخراج هنا: https://github.com/angular/angular/pull/22931

ocombe نحاول تطبيق i18n في تطبيقنا ، لكن أينما قرأت عنه أرى أننا بحاجة إلى ملف messages.xlf واحد لكل لغة. ألن يصبح ذلك عبئًا للاستمرار في التفكير في التطبيقات المعقدة ذات الشاشات المختلفة التي تواجه العملاء وما إلى ذلك .. أتطلع لمعرفة ما إذا كان بإمكاننا تفكيك ملف الرسائل لكل مكون أو لكل وحدة؟ هل هذا مدعوم بالفعل؟

@ stickler-v هذا الملف هو مجرد نقل لسلاسلك إلى برنامج الترجمة الخاص بك. لا تفكر في ترجمته يدويًا.

أرى ، أين لدينا نص فعلي بلغات مختلفة؟ نحتاج إلى إدارة هذا النص يدويًا على عكس وجود مترجمين يقومون بذلك.

آسف ، لكنني ضائع قليلا. بناءً على الوثائق الأصلية هنا https://angular.io/guide/i18n. سيحتوي src / app / app.component.html على نص باللغة الإنجليزية فقط. messages.fr.xlf هو الملف الذي يحتوي على نص فرنسي ولكن يتم إنشاؤه تلقائيًا ولا يُنصح بلمسه.

إذا كنت أرغب في عرض app.component.html باستخدام نص فرنسي بدلاً من اللغة الإنجليزية ، أين يمكنني تحديد الرسائل الفرنسية "Bonjour" وما إلى ذلك؟

@ stickler-v إنه حقًا خارج الموضوع ، يرجى إنشاء سؤال على StackOverflow. سأكون سعيدا للإجابة هناك.

هل يمكنك عدم مناقشة هذا هنا ، فهو ليس الموضوع هنا ، شكرًا
بالنسبة إلى سؤالك @ stickler-v ، ملف واحد لكل وحدة / مكون غير ممكن في الوقت الحالي ، قد يكون في المستقبل ولكنه ليس مدرجًا في قائمة الأشياء التي نعمل عليها الآن

أي خطط لدعم مسار الترجمة؟

عذرًا إذا تمت الإجابة على هذا بالفعل ولكن هل من الممكن إجراء ترجمات في JS مع هذا الإصدار أم أنها لا تزال مخصصة للقوالب فقط؟

@ santhony7 لا يزال الأمر غير ممكن لأن Ivy غير جاهز.

سؤال واحد لدي حول الغرض / وظيفة وقت التشغيل i18n هنا هو ما إذا كان هذا يعني أننا سنكون قادرين بشكل أساسي على تحديد اللغة في وقت التشغيل و "قلبها" دون إعادة تحميل التطبيق كما كانت الوظيفة في ng-translate القديم لـ AngularJS وفي ngx-translate ؟ أم أن هذا يعني شيئًا آخر تمامًا؟

لا ، سيتعين عليك إعادة تحميل التطبيق لتغيير اللغة.

باستخدام i18n الحالي ، عند إنشاء ترجماتك وتقديمها ، فإننا نستبدل السلاسل في كود الحزمة ، مما يعني أن الحزمة مترجمة.
يعني وقت التشغيل i18n أنه يتم تحميل ملفات الترجمة عند بدء تشغيل التطبيق وليس في وقت الإنشاء كما هو الحال الآن.
لهذا السبب ، ستتمكن من التحميل البطيء لملفات الترجمة قبل بدء التطبيق مما يعني أن الحزمة مفصولة عن اللغة ، وستحصل على حزمة واحدة فقط لتطبيقك.
يمكنك أيضًا اختيار الحصول على حزمة واحدة لكل لغة ، وتجميع ملف اللغة مع تطبيقك (كما نفعل الآن) ، وستتجنب التأخير المطلوب لتحميل ملف الترجمات.
في إحدى الحالات ، تقوم بطلب http إضافي ، وفي الحالة الأخرى لا ، لكنني لا أعتقد أنه سيكون هناك فرق كبير بما يكفي لتبرير وجود حزمة واحدة لكل لغة.

مزايا وقت التشغيل i18n:

• اكتشف جانب عميل اللغة ، وقم بتحميل ملف الترجمات الذي تريده كسولًا
• نظرًا لأن الرمز لا يعتمد على اللغة ، تحصل على حزمة واحدة لجميع اللغات
• يمكن أن تكون المكتبات متوافقة أيضًا مع "i18n"
• نظرًا لأننا نقوم بتحميل الترجمات في وقت التشغيل ، فلدينا كل ما نحتاجه لتقديم خدمة يمكنها إجراء ترجمات في التعليمات البرمجية الخاصة بك أيضًا (وليس القوالب فقط)
• يمكننا تقسيم الترجمات لكل وحدة (ربما لا تكون متوفرة في البداية)

سلبيات:

• الترجمة في وقت التشغيل لها تكلفة صغيرة عندما يتم استخراج الترجمات وتحويلها إلى عقد html ، ولكن نأمل ألا تلاحظ ذلك لأن Ivy سيكون أسرع بكثير من العارض الحالي
• يتأخر تشغيل التطبيق بسبب الوقت الذي يستغرقه التحميل البطيء للترجمات ، أو أن حزمتك أكبر قليلاً (إذا جمعت الترجمات)
• يتعين علينا إضافة المسلسلات إلى حزمة التطبيق الخاصة بك حتى نتمكن من قراءة الترجمات ، وهذا كثير من الشفرات (ربما يمكننا "ترجمة مسبقة" للترجمات إلى نوع من json لتجنب ذلك ، لم نقرر بعد )

من الناحية النظرية ، يمكنك تغيير اللغة دون إعادة تحميل التطبيق بالكامل ، ولكن سيتعين عليك إعادة إنشاء المكونات الحالية لأن القوالب يتم إنشاؤها عند إنشاء المكون ، أو يمكنك ربط الخدمة في القالب الخاص بك (بدلاً من استخدام i18n ) وسيتم تحديثها عند تغيير اللغة. سيكون من الممكن كتابة مكتبة تعمل مثل ngx-translate ولكنها تستخدم Angular i18n داخليًا وتسمح لك بتغيير اللغة في وقت التشغيل. سيستخدم المزيد من الذاكرة للحفاظ على القوالب متزامنة مع اللغة ، كما هو الحال مع ngx-translate. ربما سأكتب مكتبة مثل هذه.

كما يجب على الناس التفكير في أن بعض التغييرات من لغة إلى أخرى قد تكون صغيرة ، قد تكون أخرى كبيرة ، لنفترض أن الانتقال من اللغة الإنجليزية إلى الإسبانية قد يكون "صغيرًا" ولكن من الإنجليزية إلى الصينية أو العربية سيكون كبيرًا.
لتوضيح بعض اللغات ، لا يقتصر الأمر على النص فقط ، فقد تحتاج أيضًا إلى تصميم تخطيط مختلف لتلائم تلك اللغة وقواعد المحاذاة الخاصة بها ، من اليسار إلى اليمين أو من اليمين إلى اليسار وتفاصيل أخرى.

لذلك بالنسبة لمعظم استخدامات العالم الحقيقي ، أتوقع أن يحمل التطبيق في التطبيق خطوة اكتشاف اللغة التي ستؤدي إلى تحميل الموارد المناسبة وبعض التخطيطات.

ocombe شكرًا جزيلاً لك على التوضيح! لقد قمت بتطبيق Angular i18n الحالي داخل تطبيقنا وواجهت عقبة بسبب التغييرات / المتطلبات غير المعروفة. أنا أستخدم أيضًا مكتبة https://github.com/ngx-translate/i18n-polyfill جنبًا إلى جنب للمساعدة في سد الفجوة الحالية.

في حين أن الحزم المتعددة مصدر إزعاج بسيط ، يمكنك حلها بسهولة كافية حاليًا. تتمثل العقبة على وجه الخصوص في إمكانية عرض مكون واحد (وجميع المكونات الفرعية منه) بلغة مختلفة عن اللغة المستخدمة حاليًا.

بصراحة ، أنا غير متأكد حتى الآن مما إذا كان يمكن أن يساعد ngx-translate في تحقيق ذلك بالنسبة لي ، لكنني أردت إرسال رسالة إليك حول التغييرات القادمة فقط للتأكد من أن لدي أكبر قدر ممكن من المعلومات قبل إجراء أي محاور.

ليس لدينا أي خطة لدعم التطبيقات المترجمة إلى لغات متعددة في نفس الوقت ، فقد يكون من الممكن في المستقبل إذا تمكنا من تحميل ترجمات / وحدة ، ولكن سيكون ذلك أحد الآثار الجانبية للهندسة المعمارية ، وليس شيئًا نحدده على وجه التحديد حاولت تحقيقه.

هل هناك أي وقت مقدر لـ Ivy + runtime i18n؟
أتفهم تمامًا ما إذا لم يكن الأمر كذلك ، لكنني بحاجة إلى معرفة ما إذا كان بإمكاني الانتظار (نظرًا للإطار الزمني لمشروعي الحالي) أو أحتاج إلى البدء في استخدام أحد الحلول الحالية وتأجيل الترحيل إلى وقت التشغيل i18n لإصدار مستقبلي .

لن أحاول إعطاء إطار زمني محدد ، فكل مرة حاولت أن أفعلها كانت خاطئة: د
لن يكون قبل الإصدار 7 الآن (سيكون متاحًا من قبل كإصدار تجريبي)

لا مشكلة ، نحن نعلم جميعًا أن التقديرات خاطئة دائمًا. :د
هل تعتقد أنه سيكون من الأسهل الانتقال من i18n الحالي (+ i18n-polyfill) إلى وقت التشغيل 18n أو من ngx-translate؟

ربما من i18n الحالي ، لكنني سأكتب نسخة من ترجمة ngx تستخدم الأجزاء الداخلية لـ Angular i18n ، إذا كان ذلك ممكنًا (لست متأكدًا بعد)

مرحبًا ، لقد حاولت اجتياز هذا الموضوع لفهم الحالة الحالية. هل رمز ترجمة ngx هو "الحل" الأكثر قابلية للتطبيق حاليًا لتطبيق واحد باستخدام لغة محلية ديناميكية؟

مرحبًا ، هل من الممكن تغيير الترجمة في وقت التشغيل باستخدام ngx-translate / i18n-polyfill؟

suchg ليس في وقت التشغيل. يمكنك القيام بالترجمات في وقت التشغيل ولكن لا يمكنك تغيير اللغة المستخدمة.

mjschranz شكرا على الرد السريع
حتى الترجمة في وقت التشغيل جيدة في الوقت الحالي. يمكنك مشاركة أي مثال لنفسه.
لقد جربت المثال الذي تمت مشاركته على https://github.com/ngx-translate/i18n-polyfill ، وقمت بتغيير لغة متصفح Chrome ولكن لم يحالفني الحظ.
هل هناك طريقة محددة للترجمة ؟؟

من فضلك ، حافظ على المناقشة هنا حول Angular ، وليس المكتبات الخارجية. إذا كنت بحاجة إلى أي مساعدة في ذلك ، فقم بنشر الرسائل على مستودعات جيثب الخاصة بهم

مرحبًا ، هل هناك أي مشكلات تتبع أو مستندات تصميم أخرى حول الشكل الذي ستبدو عليه الميزة في المستقبل؟ ربما يمكننا المساعدة في التنفيذ أو الاستعداد للتأكد من أن الانتقال في الإصدار 7 سيكون سلسًا قدر الإمكان.

مرحبًا ، أقوم حاليًا بتشغيل Angular 5 ونحتاج إلى إضافة لغات متعددة إلى مشروعنا.
لقد أضفت حلاً يناسبني الآن ، وهو أنيق تقريبًا. https://github.com/angular/angular/issues/24549.

من الناحية المثالية ، أرغب في التحميل البطيء لملفات اللغة بناءً على خدمة شم الدولة (بناءً على بحث في خريطة اسم المضيف).
إذا كان ذلك ممكنًا في Angular 6 ، فسيكون ذلك رائعًا.

mattiLeBlanc كيف تحل الرسائل الديناميكية ، على سبيل المثال الرسائل من المكون أو الخدمات؟

zverbeta يرجى المعذرة لعدم فهم Angular Core أو سياق هذه المناقشة بشكل كامل. لا يمكنني التعامل معها إلا من السياق الخاص بي بالنسبة للمبتدئين.

للإجابة على سؤالك ، أفترض أننا مهتمون فقط بالتحميل البطيء لملفات الترجمة (xlf) بطريقة لطيفة ، بناءً على الإعدادات المحلية التي يمكن استنتاجها من عنوان URL أو من معلمة استعلام اللغة. (أستخدم حاليًا خريطة URL لتحديد اللغة).

لم يتم وضع علامة على رسالة من مكون أو خدمة كما نضع علامة على الترميز بـ i18n. لدي بعض الخبرة مع i18n لـ Wordpress و PHP. هناك نستخدم الأسلوب __( 'text' to translate, 'text domain' ) للحصول على الترجمة الصحيحة. يمكن أيضًا فحص __() هذا بواسطة أمر CLI الذي ينشئ ملف الرسالة.

هل هذه من القضايا التي تشير إليها؟

شيء واحد لاحظته مع كتلة الترميز هذه على سبيل المثال (لأنني كنت كسولًا ولم أرغب في إضافة i18n في كل عنصر فرعي):

<div class="eligibility-banner" i18n="@@eligbilityBanner" fxLayout="column" fxLayout.gt-xs="row" fxLayoutAlign.gt-xs="center center" fxLayoutAlign="center start">
        <div class="requirement-text" fxFlex="20">To be eligible, you:</div>

        <div fxLayout="column" fxFlex="80" fxLayout.gt-xs="row" fxLayoutAlign="center start">
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">own an Australian business (with a valid ABN/ACN)</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are over 18 years old</div>
          </div>
          <div fxLayout="row" fxLayoutAlign="center center" class="requirement" fxFlex="33">
              <pro-svg icon="icon-check-circle" className="icon-check" width="44" height="44"></pro-svg>
              <div class="text">are an Australian Citizen or Permanent Resident</div>
          </div>
        </div>
      </div>

هذا هو نسخ كتلة div بأكملها في رسالتي. xlf.
هذا هو الكثير من التلوث الترميز. (بالطبع يمكنني استخدام i18n في كل علامة تحتوي على نص.)

في هذا المثال ، أعتقد أن استخدام الأمر _e() سيعمل بشكل جيد. ستقوم بلف نصك بأمر echo وسيتم جمع كل تلك النصوص الملتفة. يمكنك التخلص من كل نسخة الترميز هذه في ملف xml.
إذا كنت بحاجة إلى إضافة شيء ديناميكي إلى هذه السلسلة ، فيمكنك توجيهها باستخدام حوامل مكان في السلسلة (كما تفعل مع sprintf . شيء مثل

<p>{{ __( 'I would like a nice %s, please', fruit ) }}</p> 

حيث fruit متغير بقيمة __( 'apple') أو __( 'pear) .
ستنتهي الأجزاء الثلاثة من النص في XML ويمكن ترجمتها بشكل منفصل.

هل هذا مفيد؟ إنه مشابه جدًا لإضافة سمة i18n ، أدركت بعد القراءة مرة أخرى :)

أخيرًا ، بالنظر إلى اثنين من التنسيقات. يبدو XLIFF 2 لطيفًا جدًا ، وأنظف قليلاً من 1.2. يبدو أن XMB وثائق محيرة ومروعة تبدو كما لو كانت على غرار عام 1995.
لقد لاحظت عند استخدام XLIFF 2 أن نص TARGET لم يتم تقديمه كما هو الحال في الإصدار 1.2.

هل نظرتم يا رفاق في ملفات .pot و .mo؟ تنسيق بسيط جدًا ويستخدمه أيضًا مترجم بأداة POEdit.

أحتاج إلى تحويل طلبي باللغتين الإنجليزية والإسبانية باستخدام زر التبديل. فعلت كل التغييرات ، ملف العمل بشكل منفصل. لقد قمت بإنشاء بناءين تحت .dist / en و dist / es. هل يمكن لأي شخص أن يخبرني ، ما الذي يجب علي فعله للنشر وكيفية التبديل بين كلا الإصدارين؟

ما أحتاج إلى القيام به عند النقر فوق زر التبديل

@ shobhit12345 يرجى نشر طلب المساعدة الخاص بك على https://stackoverflow.com

zverbeta الحل الذي نشرته في # 24549 لا يعمل عندما أنشيء باستخدام --prod . من الواضح نوعًا ما لأنني أستخدم require والذي ربما لا يكون متاحًا؟
بدون علامة --prod ، هل يعمل الحل لأنه يتضمن رمزًا متعلقًا بحزمة الويب؟

mattiLeBlanc لقد وجدت هذا lib https://github.com/ngx-translate/i18n-polyfill وهو يحل مشكلتي مع النص الديناميكي

مرحبًا ، كيف يمكننا ترجمة القيم الديناميكية (الاستيفاء) باستخدام i 18 n.

    <source>This amount is for <x id="INTERPOLATION" equiv-text="{{policyName}}"/> policy #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></source>
    <target>Esta cantidad es para <x id="INTERPOLATION" equiv-text="{{**policyName**}}"/> política #<x id="INTERPOLATION_1" equiv-text="{{policyGroupId}}"/></target>

يا! هل هناك أي مكان يمكننا فيه تتبع و / أو المساعدة في المهام التي تم العمل عليها؟ (الأشخاص الذين يعملون عليها علامة)

أي تحديثات على الإطار الزمني لإصدار نسخة تجريبية من وقت التشغيل i18n؟

marcelnem لا يمكنني العثور على التعليق لكن iirc ocombe ذكر أن وقت التشغيل i18n مدمج مع Ivy لذا يمكنك على الأرجح اختباره على الإصدار 7 بيتا بعلامة Ivy

تم الانتهاء من جزء وقت التشغيل ولكن ليس جزء المترجم ، مما يعني أنه لا يمكنك اختباره بعد باستخدام Ivy

مرحبًا ، أنا أعمل مع Angular 6 i18n. أنا أعمل بلغات متعددة ، وهذا يعني أنني اتبعت كتاب الطبخ:
https://v2.angular.io/docs/ts/latest/cookbook/i18n.html#!

يستخدم تطبيقي الحالي AOT ، لذلك قمت بإنشاء ملف messages.xlf و messages.pt.xlf. كل شيء يسير على ما يرام عندما أركض

خدمة ng - التكوين = pt

أحصل على نصوص مترجمة كما هو متوقع. لكني أشعر أن هناك شيئًا خاطئًا جدًا في طريقة عملها. ربما أفتقد شيئا. بقدر ما فهمت ، في كل مرة أقوم فيها بإضافة سلسلة جديدة ليتم ترجمتها وتمييزها بسمة i18n ، أحتاج إلى إعادة إنشاء ملف messages.xlf الذي يعمل "ng xi18n" ثم تحديث message.pt.xlf يدويًا. يحتوي ملف xlf أيضًا على رقم السطر حيث يوجد المصدر ، لذلك يبدو أنه إذا قمت بتغيير الصف ، فسوف أحتاج أيضًا إلى إعادة إنشاء الملف وتحديث ملف pt يدويًا.

<context context-type="linenumber">16</context>

هذا لا يبدو ذكيًا ، سوف يمنحني الكثير من العمل الإضافي لإبقائه يعمل. هل تفهم قلقي؟ هل فاتني شيء؟
أعلم أن Angular 7 i18n ستحصل على تحديث كبير مع دمج Ivy ، فهل يجب أن أنتظر ذلك؟

أنا في حاجة إليها،
فابيو

ملاحظة آمل حقًا ألا يكون هذا خارج الموضوع ، ولكن إذا شعرت أنه كذلك ، فيرجى إعطائي اتجاهًا على الأقل. أين يجب أن أسأل هذا على سبيل المثال؟ أو إذا كان هناك رابط قد يجيب على شكوكي.

fabiopcarvalho من الأشياء التي أدركتها أنه من الحكمة استخدام معرفات مخصصة لكل ترجمة لتسهيل تتبع التغييرات في تخطيط HTML.

لكن نعم ، سوف تحتاج إلى تحديث ملف الترجمات بشكل روتيني.

fabiopcarvalho أستخدم xliffmerge لمساعدتي في دمج الترجمات

ممتاز ، لقد استخدمت تلك الأداة وعملت بشكل رائع. أنا أيضًا أستخدم المعرفين و
يفعلون المساعدة.
شكرا على الرد !!

في يوم الخميس 30 أغسطس 2018 ، كتب Pedro Romero [email protected] :

fabiopcarvalho https://github.com/fabiopcarvalho استخدم xliffmerge
https://github.com/martinroob/ngx-i18nsupport لمساعدتي في الدمج
من الترجمات

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/angular/angular/issues/16477#issuecomment-417407822 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AWOWQ6vpjOb0Ntgpv7TUngRrBBsUIkVjks5uWCV7gaJpZM4NOSBk
.

يُعد السماح برسائل وحدة العناية المركزة في السمات أمرًا بالغ الأهمية لإمكانية الوصول لأن سمة aria-label تُستخدم كثيرًا في إمكانية الوصول. هل هناك مشكلة للمتابعة؟

لا أعتقد أن هناك مشكلة في ذلك ، هل يمكنك فتح واحدة؟ أنا أعمل على تعبيرات وحدة العناية المركزة الخاصة باللبلاب في الوقت الحالي ، لذا أضفت TODO ، لكن طلب الميزة سيكون أفضل

ocombe ، https://github.com/angular/angular/issues/21615

شكرًا جزيلاً (بحث Github سيء حقًا!)!

هل سنتمكن من التحميل البطيء لملفات الترجمة من مصدر خارجي على سبيل المثال عبر HTTP مع الإصدار الجديد من i18n؟

ocombe كما قلت إنك تعمل على Runtime i18n (حزمة واحدة لجميع اللغات مع AOT). لقد مر أكثر من عام ونحن ننتظر. متى نتوقع هذه الميزة هل ستأتي في إصدار 7 الزاوي؟

@ Sef1995 إنه أحد الأشياء التي نريد تمكينها
AhmadShahid سيتطلب Ivy والذي سيتم إصداره بشكل مستقل عن الإصدار 7 ولن يكون Ivy جاهزًا لإصدار الإصدار 7. توجد بعض أجزاء Ivy بالفعل في الإصدار 6 خلف العلم ، ولكنها ليست ميزة كاملة ولا يجب عليك استخدامها في تطبيق العالم الحقيقي. ليس لدينا تاريخ إطلاق لبلاب حتى الآن.

ocombe سؤال سريع ، إذا قمنا بتطبيق i18n اعتبارًا من اليوم (angular6) ، والذي سيتطلب تصميمات مختلفة (واحدة لكل لغة) ، فهل يضيع الجهد عند خروج Ivy ووقت تشغيل i18n؟ أعني الطريقة التي سيتم بها تطبيق i18n الآن ستختلف عما هو قادم؟ محاولة التخطيط لبعض سباقات السرعة مسبقًا وتحديد أولويات العمل. شكرا

لا نريد إنشاء تغييرات عاجلة إذا تمكنا من تجنبها. قد تتغير معرفات الترجمات المستخرجة عندما نصلح الأخطاء التي كانت لدينا منذ فترة طويلة ، لكننا سنقدم أداة ترحيل. لا يمكنني القول على وجه اليقين أنه سيكون متوافقًا بنسبة 100٪ ، ولكن أتوقع أن تعمل معظم الأشياء بنفس الطريقة ، مع توفر خيارات جديدة للاستخدام إذا كنت تريد ذلك.

ocombe سؤال سريع ، إذا قمنا بتطبيق i18n اعتبارًا من اليوم (angular6) ، والذي سيتطلب تصميمات مختلفة (واحدة لكل لغة) ، فهل يضيع الجهد عند خروج Ivy ووقت تشغيل i18n؟ أعني الطريقة التي سيتم بها تطبيق i18n الآن ستختلف عما هو قادم؟ محاولة التخطيط لبعض سباقات السرعة مسبقًا وتحديد أولويات العمل. شكرا

مرحبًا ، يمكنك استخدام حزمة الويب المطلوبة لتحميل الملفات ديناميكيًا (كحل مؤقت) ببنية واحدة:
يمكن العثور على مثال هنا: https://github.com/angular/angular/issues/24549#issuecomment -402013622

يجب عليك البناء باستخدام --prod --aot = false ، نظرًا لأن AOT = true ستزيل عناصر حزمة الويب.

ocombe مرحبًا ،

خرج مرشح إصدار A7 ، فكما وعدنا ، هل نقوم باختبار ترجمة وقت التشغيل ؟. Runtime i18n (one bundle for all locales with AOT) . كيف يمكنني اختبار هذا. الرجاء المساعدة

شكرا

أنا أؤيد السؤال من sheikalthaf على الرغم من إصدار v7 بالفعل.

sheikalthafShuyinsama كما أوضح بعض التعليقات أعلاه وفي الرسالة الأولى:
يتطلب وقت التشغيل i18n إصدار Ivy والذي سيتم إصداره بشكل مستقل عن الإصدار 7. توجد بعض أجزاء Ivy بالفعل في الإصدار 7 خلف علامة ، ولكنها ليست ميزة كاملة ولا يجب عليك استخدامها في تطبيق حقيقي. ليس لدينا تاريخ إطلاق لبلاب حتى الآن.

ocombe : ماذا عن تمرير مفتاح i18n الديناميكي من العنصر الأصل إلى المكون الفرعي.

المكون الفرعي:
<div i18n="{{labelTextKey}}">{{labelText}}</div>

المكون الرئيسي:
<app-input [labelText]="'Second name'" [labelTextKey]="'@<strong i="13">@LabelSecondName</strong>'" ..></app-input>

يمكنني تمريرها ، ولكن نظرًا لأن ترجمة i18n تحدث في وقت الإنشاء ، فإن المتغير في هذه الحالة لا يزال فارغًا. لذلك ، لا تحدث أي ترجمة.

أي تحديث لمثل هذه الحالة؟

تضمين التغريدة

لست بحاجة إلى علامة i18n في المكون الفرعي ، يمكنك فقط استخدامها في الوالد مثل هذا:

<app-input i18n-labelText="@@LabelSecondName" labelText="Second name"></app-input>

cjsase : العمل الرائع. تشكرات! كان يكافح مع ما يقرب من يومين.

بناءً على ذلك: https://github.com/angular/angular/issues/21706#issuecomment -430435254

• لا ينبغي أن نتوقع لبلاب في الإصدار 7. تم التخطيط v8 لشهر مارس / أبريل 2019 . إذا كان يجب ألا نتوقع Ivy في الإصدار 7 ، فهل هناك توصية / إجماع حول ما يجب استخدامه للتدويل (i18n) حتى يتم إصدار Ivy في أبريل 2019؟

هذه معلومات غير صحيحة. لم يقل الفريق الأساسي مطلقًا أنه سيتم إصدار IVy في عام 2019. وبدلاً من ذلك ، قال الفريق الأساسي (التركيز مني):

يجب إصداره في أي إصدار ثانوي ، متى تم اختباره والتحقق من صحته

لنفترض أن لديّ تطبيق 7.1.0-beta.0 الزاوي مع تفعيل Ivy ، فهل يمكنني الحصول على إعداد مع تغيير لغة ديناميكي صادر من الأمام بدون تحديث الصفحة؟

اذا نعم كيف؟ هذا المستند: https://github.com/angular/angular/blob/master/aio/content/guide/i18n.md
وهذا المستند: https://angular.io/guide/i18n

لا تعرض هذا؟

أين يمكنني تعلم كيفية إنشاء تطبيق i18n-angular حديث / مستقبلي؟

tatsujb لا ليس ممكنًا ، ولن يكون ممكنًا حتى مع Ivy & runtime i18n. سيتعين عليك إعادة تحميل تطبيق Angular إذا كنت تريد تغيير اللغة في الوقت الحالي

حسنًا ، لكن المستندات تنطبق نوعًا ما على نسخة خيالية من الزاوية مثل 4 ناقص.

لا أشعر أنهم ينطبقون على الإعداد الخاص بي كما أنهم لا يغطون كيفية تطبيق التغيير بالضبط.

أنا أعتبر أن التغيير يجب أن يتم فرضه بواسطة الخلفية.

في حالتي ، يتم تقديم الزاوية الخاصة بي في وضع الإنتاج بواسطة خلفية java-spring. ما هي الخطوط الكبيرة لما سيحدث عندما أضغط على أيقونة العلم لتغيير اللغة؟

تأخذ المستخدم إلى www.yourdomain.com/cn/ حيث يتم تجميع تطبيق Angular بالكامل باللغة الصينية. ينتهي بك الأمر مع تطبيق Angular مترجم كامل لكل لغة تريد دعمها.

ocombe @ santhony7 وماذا عن هذا: https://github.com/actra-development-oss/ng-i18n-aot-loader ؟

ممكن اجرب هذا

هل هي متوافقة بشكل سيء مع 7.1.0-beta.0 أم أنها متوافقة بشكل لائق؟

ocombe @ santhony7 وماذا عن هذا: https://github.com/actra-development-oss/ng-i18n-aot-loader ؟

ممكن اجرب هذا

هل هي متوافقة بشكل سيء مع 7.1.0-beta.0 أم أنها متوافقة بشكل لائق؟

أوصي باستخدام ngx-translate بدلاً من ذلك. لقد استخدمت كل من ngx-translate وهو أسهل بكثير في الصيانة.

digismack هناك اختلاف آخر بين الاثنين ، وهو أمر مخيف بعض الشيء وهو أن ngx-translate تسقط كل عناصر angular-i18n الرسمية ولا تستخدم أيًا منها على الإطلاق. إنها دائرتها المستقلة بالكامل وملفات json أقل تحديدًا حول مصادر الترجمات.

أيضًا من بين العرضين التوضيحيين ngx-translate يبدو أبطأ بكثير ، ماذا تقصد عندما تقول أنه كان من الأسهل الحفاظ عليه؟

tatsujb بصفتي مطور th ng-i18n-aot-loader ، أعلم أنه من الصعب تنفيذها ، على الأقل دمج اللوادر.
كل شيء آخر هو قطعة من الكعكة لأنها تتبع نماذج i18n الزاويّة الأصلية.

يجب أن يعمل مع الإصدار 7 طالما لم تكن هناك تغييرات متقطعة في هياكل العلامات أو ما شابه ذلك.

في محاولة لتطبيق ngx-translate ، لا بد لي من الانتقال إلى مكان قابل للترجمة حسب مكان قابل للترجمة. هناك المئات من السخف بعض الشيء بالنسبة لي أنني لا أستطيع استخدام علامات i18n الخاصة بي التي خططت لها مسبقًا.

بدأت أعتقد أن الوثوق بك كان الاختيار الخاطئ ، digismack

tatsujb هناك 58 شخصًا يتابعون هذه المشكلة. أنا شخصياً أتابعها للحصول على تحديثات من فريق Angular بخصوص i18n. سأكون ممتنًا إذا أوقفت الثرثرة ما لم تكن مرتبطة بما ينص عليه البروتوكول الاختياري:

إذا كنت تريد إضافة ميزات i18n جديدة إلى Angular ، فلا تتردد في السؤال أدناه وسأخبرك إذا كان ذلك ممكنًا وما إذا كان يجب عليك فتح مشكلة لذلك.
إذا كان لديك خطأ ، فافتح مشكلة (لا داعي للمناقشة حوله هنا).

إذا كانت لديك مشكلات مع مكتبات أخرى ، أقترح طرح سؤال على StackOverflow.

ليس من عادتي أن أكتب / أعلق على الموضوع ... لكنني سأفعل!
مع مراعاة :
gtbuchanan و CO هما النوع "أ" من الأشخاص.
tatsujb وغيرهم من الأشخاص الذين يشكون / يعلقون / يتوقعون الأشياء من النوع B من الشخص

اكتب أ لست متعبًا من تكرار نفس الأشياء دائمًا؟!؟! بالنسبة لي ، أنت مزعج أكثر من النوع ب.

بسبب فقدان ميزة i18n في النوع B الزاوي ، يشعر الأشخاص بالإحباط أكثر منك الذين "اشتركوا" في مشكلة ما (إذا كان الهدف هو تكوين صداقات لك ، فاكسب بعض الإعجابات ، اذهب إلى facebook لا أعرف ، لا يوجد مكان لذلك فلن تغير الكلمة ولا تخترع شيئاً يقول ذلك! ...)

أعتقد أن النوع A يمكنه إلغاء الاشتراك ، أو انتظار التحديث ، أو التحقق من سجل التغيير بسرعة أو قراءة المدونة / الأخبار ، تأكد من أن الفريق الزاوي سيضعه بخط كبير ARIAL 72pixel حيث يقدم ترجمة ديناميكية i18n من ts + runtime i18n: ميزة كبيرة مفقودة في الزاوية! لم يفكروا في الأمر بشكل كبير ، لذلك ليس لدينا i18n الصحيح اليوم ، فهذه استراتيجية من Google أو نحو ذلك ولا يمكن تغيير هذا!

ينتظر الأشخاص B هذه الميزة منذ عامين ، https://github.com/angular/angular/issues/9104#issue -159302131 نعم منذ الزاوية 2.X!

أريد فقط أن أقول من فضلك احترم النوع ب المحبط ولا تكن شريرًا. إذا لم يشكو أحد كثيرًا من i18n ، فأعتقد أن تحسين i18n لن يُؤخذ في الاعتبار لسنوات قادمة ، فهذا جزء من المصدر المفتوح أيضًا! يشكو النقاد! يمكن أن تتغير الإستراتيجية! لذا اترك الناس يشتكون ، إلغاء الاشتراك ، فأنت أفضل من غيرك ، حيث يمكنك العثور على معلوماتك دون الاشتراك في هذه المشكلة!

اكتب B ، يرجى الاستمرار في الشكوى / التعليق حتى تتمكن من ذلك! إنها الطريقة الوحيدة الأفضل لفهم احتياجات الناس!

سترايك سترايك لول

tatsujb كل هذا يعود إلى التفضيل الشخصي. عندما قمت مؤخرًا بتطبيق ng-i18n-aot-loader ، اضطررت إلى تشغيل بنية مقذوفة وتخصيص تهيئة حزمة الويب من أجل تشغيلها. ربما لم يعد هذا هو الحال. ومع ذلك ، فإن تشغيل بنية مقذوفة يعني أن أدوات Angular CLI لم تعد قابلة للاستخدام. لذلك ، وجدت أنه من الأسهل على المدى الطويل تنفيذ ngx-translate والتعامل مع حقيقة أنه يعمل بشكل مختلف قليلاً.

gtbuchanan أشعر بألمك ، لكن هذه "الثرثرة" مرتبطة مباشرة بنطاق الميزات المذكورة في منشور OP. نظرًا لاستمرار الإطار الزمني لـ Runtime i18n (one bundle for all locales with AOT) في الانزلاق ، لا يزال الأشخاص يأتون إلى هذا الموضوع للبحث عن الحلول الحالية.

ocombe ، نحن على وشك بدء مشروع جديد الآن ، حيث سنحصل على الترجمات من قاعدة بيانات.
سيتم تحميل وحدات Angular الخاصة بنا بشكل كسول ونود أيضًا أن نكون قريبين قدر الإمكان مما تقدمه Angular فيما يتعلق بـ I18N.

نظرًا لأن دعم Angular I18N لم يتم إدخاله في الإصدار الأخير كما هو مخطط له - هل لديك أي توصية لنا وللآخرين الذين يدورون حول إنشاء مشاريع جديدة الآن؟

على سبيل المثال ، حتى يصبح I18N جاهزًا ، يمكننا استخدام ngx-translate ، لكن بعد ذلك قرأت في مكان ما في قضايا github الخاصة بهذا المشروع ، أنه لن يدعم التحميل البطيء ، والذي سيكون بمثابة توقف للعرض بالنسبة لنا.

ومن ناحية أخرى ، فإن دعم Angular's I18N ليس جاهزًا لوقت الذروة حتى الآن.

أود حقًا أن أفهم بعض التلميحات التي توجهنا إلى الاتجاه الصحيح حول ما يجب استخدامه للمشروع القادم - ngx-translate vs؟

يجب أن تملكه:

• تحميل كسول

من الجميل أن يكون لديك:

• تعابير وحدة العناية المركزة

ميرسي

لمتابعي هذه المشكلة ، سيتحدثocombe عن وقت التشغيل i18n في angularconnect في غضون ساعتين. أفترض أنه سيتم الرد على بعض الأسئلة المفتوحة على الأقل هناك. هناك بث مباشر متاح

ctaepper - شكرًا جزيلاً على المعلومات!

guygit قد يكون هذا ngx-translate أو angular-l10n . ها هو جدول المقارنة الذي أنشأته https://medium.com/@sergeyfetiskin/tools -to-translate-your-angular-app-c021e25ff26a

بالنسبة لتطبيقاتنا ، قررنا أن نسلك الطريق الزاوي حتى مع وجود بعض القيود.

fetis شكرا جزيلا لك - سألقي نظرة :-)

أتساءل عن اختيار ملفات XLIFF لملفات الترجمة - مجموعة أدوات الترجمة من Google وكذلك Flutter / Dart i18n يدعمان ملفات ARB ولا يدعمان XLIFF. لقد سمعت أن دعم ملف ARB ليس مخططًا له ، ولكن أتساءل عما إذا كان هذا أمرًا يمكن النظر فيه مرة أخرى. أو إذا كان بإمكان شخص ما ( ocombe ؟) الإشارة إلى المكان الذي يتفاعل فيه Angular مع ملفات XLIFF حتى أتمكن من إلقاء نظرة على مدى صعوبة دمج دعم ARB.

(بالنسبة إلى بعض السياقات ، سنستخدم Flutter / Dart لتطبيقات الأجهزة المحمولة و Angular لتطبيق الويب الخاص بنا ، ونود حقًا مشاركة ملفات الترجمة الخاصة بنا بين كل من الجوال والويب إذا كان ذلك ممكنًا. أفكر في كتابة ARB -> محول XLIFF إذا لم تكن هناك شهية للنظر في إدراجه في Angular.)

localpcguy إذا انتهى بك الأمر إلى كتابة نوع من المحول ، فقد تكون مهتمًا بالمساهمة به في https://github.com/translate/translate الذي يقدم بالفعل تحويلًا من / إلى الكثير من التنسيقات.

في ملاحظة جانبية ، قال ocombe قبل بضعة أشهر إنه سيضغط بقوة لدعم ملفات PO (و JSON؟). نأمل أن يحدث ذلك في مرحلة ما ، لأننا واجهنا صعوبة في العثور على أدوات ockay-ish للعمل مع XLIFF.

لأننا واجهنا صعوبة في العثور على أدوات ockay-ish للعمل مع XLIFF.

PowerKiKi هذا ببساطة ليس صحيحًا. تدعم أي أداة لإدارة الترجمة عبر الإنترنت تقريبًا تنسيق XLIFF. وهناك أيضًا برامج ترجمة مجانية لسطح المكتب إذا كنت لا ترغب في تحرير .xliff يدويًا

fetis أنا أكره الخروج عن الموضوع ولكني وجدت الكثير من الألم فيما يتعلق باستخدام XLIFF مع الأدوات. انظر تعليقي هنا: https://github.com/angular/angular/issues/20193#issuecomment -345755889

يرجى تقديم مراجع لهذه الأدوات ، لأننا ما زلنا لم نعثر على أي شيء جيد ولا يزال يتعين علينا العثور على شيء يدعم XLIFF 2. تبدو Smart Cat جميلة ولكن تحديث السلاسل فيها يجعلني أرغب في قياس نظري.

يبدو أنك تعرف شيئًا لا نعرفه :)

يستخدم Pootle https://github.com/translate/translate وكان رائعًا حقًا مع Gettext (ملفات po) ولكنه لا يدعم العناصر النائبة / العلامات وينتظرون مساهمة من شخص ما لإضافتها

لقد اشتركت في هذه المشكلة لمدة عام طويل أو نحو ذلك. يبدو أن التقدم في هذا الصدد ليس أولوية بالنسبة لفريق Angular ، ومن غير المقبول الاضطرار إلى تجميع التطبيق مرة واحدة لكل لغة والقيام بالترجمات الديناميكية. أوصي ، إذا كنت قادرًا على القيام بذلك ، بإنشاء أنبوب مخصص يستخدم أيًا من مكتبة i18n الأخرى التي تريدها. نظرًا لكونه نقيًا ، فسيكون هذا الأنبوب فعالًا بنفس القدر في تجميع التطبيق عدة مرات. أيضًا ، باستخدام i18n الذي لا يعتمد على Angular ، ستتمكن من إجراء ترجمات ديناميكية من التعليمات البرمجية بشكل تافه. ميزة أخرى هي أن ترجماتك لن تعتمد بعد الآن على Angular ، لذا يمكنك البدء في ترحيل بعض المكونات إلى أطر أخرى إذا كنت ترغب في ذلك ، أو يمكنك حتى اختيار تنسيق الترجمة والأدوات التي تفضلها بحرية كاملة. أنا أستخدم https://airbnb.io/polyglot.js/ وأنا سعيد جدًا به ، وحتى عندما يستمر ترحيل تطبيقي من Angular i18n إلى متعدد اللغات ، لا يمكنني أن أكون أكثر سعادة بالنتيجة والإزالة من التبعية مع Angular i18n.

آسف لأولئك الذين سيتلقون هذا كإشعار على بريدك ولا يهتمون برأيي ، ولكن نظرًا لقراءة إشعاراتك لفترة طويلة ، أشعر أنني يجب أن أقول وداعًا قبل إلغاء الاشتراك :)

هتافات!

يبدو أن التقدم في هذا الصدد ليس أولوية بالنسبة لفريق Angular ، ومن غير المقبول الاضطرار إلى تجميع التطبيق مرة واحدة لكل لغة والقيام بالترجمات الديناميكية.

وقت التشغيل i18n هو أولوية كبيرة لفريق Angular. ومع ذلك ، فإن مشكلة الحظر هي عارض Ivy الجديد. إن تقدم المشروع جيد حتى الآن ويمكننا أن نتوقع على الأرجح Ivy for Angular 8. أفهم أن هذا وضع صعب لجميع المعنيين. هناك خطط ولكن لا يمكن تنفيذها طالما لم يتم الانتهاء من Ivy.

يرجى الاطلاع على المحادثات من مؤتمر AngularConnect الأخير (2018) في لندن ، وخاصة "Runtime i18n" لأوليفييه كومب والخطاب الرئيسي لليوم الثاني من قبل أليكس ريكابو.

في الواقع تجربتي مشابهة لـintellix.

يبلغ عمر XLIFF 1.2 10 سنوات ، ومع ذلك يبدو أن الدعم له في المشاريع مفتوحة المصدر ضعيف للغاية. لا يدعم Pootle أصحاب البصيرة وفقًا لـ https://github.com/translate/pootle/issues/4762 و https://github.com/translate/pootle/issues/1811. Weblate لا يدعمهم أيضًا ، على الرغم من أن العلاقات العامة قد تضيف الدعم قريبًا .

على سطح المكتب ، تدعم Virtaal _does_ العناصر النائبة لـ XLIFF ، ولكن الإصدار الأخير 0.7.1 عمره 6 سنوات ولم يعد يعمل على أحدث إصدار من macOS مما سمعته. لسوء الحظ ، لا يعطي انطباعًا بوجود مشروع يتم صيانته جيدًا ، مع وجود عدد قليل من العلاقات العامة القديمة جدًا التي لا تزال تنتظر دمجها على الرغم من بساطتها الواضحة. ونشاط التزام منخفض جدًا في السنوات القليلة الماضية .

لقد اكتشفت للتو أن برنامج Poedit 2.2 الذي تم إصداره قبل بضعة أيام يدعم XLIFF 1.2 و 2.0. للأسف لا يمكنني اختباره لأنني أتلقى خطأ من snapcraft.io CDN عند التثبيت في الوقت الحالي. ولكن قد يكون هذا هو الحل الأفضل لمستخدمي سطح المكتب.

fetis إذا وجدت بعض المشاريع مفتوحة المصدر (أو على الأقل مجانية الاستخدام) لتحرير XLIFF 1.2 ، أو أفضل من XLIFF 2.0 ، مع دعم العناصر النائبة ، يرجى إدراجها هنا. كل شيء آخر اختبرته كان إما أنه لا يعمل على الإطلاق ، أو أنه معقد للغاية للاستخدام.

intellixPowerKiKi ها هي القائمة التي أعرفها. هدفنا هو منصة ترجمة عبر الإنترنت ، حيث يمكننا التعاون مع مترجمين / زملاء من دول مختلفة. لا تعد عملية تثبيت برنامج سطح المكتب لكل متعاون وإدارة مزامنة ملفات XLIFF خيارًا بالنسبة لنا. لذلك ، لم أختبر أدوات سطح المكتب ، والأنظمة الأساسية التي قمت بها.

التطبيقات
أوميغا
https://omegat.org/

الاستضافة الذاتية
https://weblate.org/ar/ + استضافة مدفوعة
https://pootle.translatehouse.org/
https://pontoon.mozilla.org/

المنصات
الحشد في
https://crowdin.com/
دعم CLI

WebTranslateIt
https://webtranslateit.com/
دعم CLI

Transifex
https://www.transifex.com/

PhraseApp
https://phraseapp.com/

لوكاليس
https://lokalise.co/
دعم CLI

_ أعتقد أننا سننتهي مع Lokalise لمشاريعنا لأنها توفر وظائف كافية وبأسعار في متناول الجميع.

~ POEditor ~
https://poeditor.com/pricing/
لا يعمل دعم XLIFF المعلن مع تنسيق Angular

إذا كنت تبحث عن حل مفتوح المصدر ، فقد تكون هذه القائمة مفيدة لي https://opensource.com/article/17/6/open-source-localization-tools

العقد الجانبية
لم أر منصة على الإنترنت تدعم XLIFF 2.0 وكانت مفاجأة كبيرة بالنسبة لي. تم وضع علامة على XLIFF 1.2 رسميًا على أنه مهمل ولم يدعم أي شخص في الصناعة الإصدار 2.0.

سعيد لسماع أن POEdit أعلن دعم XLIFF ، لقد استخدمته لملفات .po وكان ذلك لطيفًا.

ملاحظة: يؤسفني جدًا إنشاء ملف خارجي هنا ، ولكن في نفس الوقت ، يعد الحصول على ملف XLIFF من تطبيقك جزءًا فقط من الرحلة ، فأنت بحاجة إلى ترجمته وصيانته خلال دورة حياة تطبيقك. لذا فهي مناقشة مهمة. أود أن أقترح الانتقال إلى مكان ما ، يمكنني وضع هذه القائمة كمقال متوسط ​​ويمكننا مواصلة المناقشة هناك.

localpcguy ، هناك العديد من التنسيقات ، ولكن كل هذا يتوقف على عدد التنسيقات التي يمكننا دعمها. تستغرق كتابة المسلسل وصيانته وقتًا. تمت إضافة Xliff 2 كعلاقات عامة من قبل شخص آخر ، ولهذا السبب أضفنا الدعم (وإلا لما استغرقت الوقت لدعمه).
نحتاج إلى مُسلسل لشيئين: الاستخراج والدمج.
لم أتحدث عن هذا في Angular Connect ، لكن آمل أن نتمكن من استخدام جهاز تسلسلي خارجي. يجب أن يكون من السهل جدًا القيام بذلك لوقت التشغيل (الدمج) مع Ivy ، لكن الاستخراج لا يزال معقدًا لأن المسلسل يحتاج إلى التحديث عندما نجري تغييرات على المترجم.
لدي بعض الأفكار حول كيفية القيام بذلك ، لكن يجب أن أتحدث إلى الفريق حول هذا الأمر بمجرد هبوط اللبلاب. ما أود فعله حقًا هو إضافة دعم JSON على الأقل حتى أتمكن من إعادة كتابة ترجمة ngx باستخدام Angular i18n (ولأن الكثير من الناس يريدون ذلك).

شكرًا ocombe (وجميع المدخلات الأخرى ، أحب رؤية وجهات النظر المختلفة). يبدو أن # 14185 هو العلاقات العامة التي ذكرتها ، فهل هذا لا يزال نقطة انطلاق جيدة إذا كنت أرغب في إضافة دعم ARB؟ هل هذا شيء يمكن دمجه إذا تم تقديمه؟

localpcguy لدينا اجتماع غدًا حيث سنناقش ذلك (وأشياء أخرى) ، وسأخبرك كيف ستسير الأمور

حسنًا ، إليك ما نعتقد أنه سينجح: بالنسبة للاستخراج ، سنستخرج السلاسل في نوع من تنسيق json (قد يكون ARB نظرًا لأنه تنسيق json رسمي للترجمات) يمكن لأي شخص إجراؤه ومعالجته بعد ذلك إلى أي تنسيق تريد استخدامه (json سهل الاستخدام حقًا) ، ولوقت التشغيل سنوفر نوعًا من الواجهة التي يمكنك استخدامها لكتابة أداة التحميل الخاصة بك التي تفهم التنسيق الخاص بك.

يعني هذا إلى حد كبير ، أننا أحرار في استخدام أي نوع من التنسيق للترجمات طالما أنه يمكننا توفير أداة تحميل للتطبيق؟

حسنًا ، سيكون هذا رائعًا: +1:

نعم ، لن تتمكن من الوصول إلى التحسينات العميقة (استبدل السلاسل في وقت الإنشاء لإنشاء حزمة واحدة لكل لغة ، مما يعني أن الترجمات سيتم تقسيمها باستخدام مكوناتك) ، ولكن يمكنك استخدام أي نوع من حلول التحميل البطيئة التي تريدها ، طالما قمت بتحميل جميع الترجمات عند بدء تشغيل التطبيق (يجب تحميلها بشكل متزامن قبل إنشاء أحد المكونات)
يمكنك أيضًا في النهاية تقسيمها يدويًا وتحميلها باستخدام جهاز التوجيه بشكل غير متزامن عند تحميل مكون جديد ، سيكون هذا الأمر متروكًا لك ، باستخدام وظائف التحميل البطيئة الجديدة التي يوفرها Ivy (قام Jason بعرض تجريبي لذلك في Angular Connect)

هل يمكن أن نتوقع عرضًا تجريبيًا تجريبيًا (وليس ملفات فيديو أو بثًا مباشرًا فقط) لتبديل اللغة أثناء التنقل على Ivy؟ قد تكون محاولة تجميع اللبلاب قبل النهائي POC طريقة رائعة للكشف عن قنابل الخط.

لا يعني ذلك أنني لا أوافق على نهج انتظار المزيد من حجر اللبلاب الثابت قبل أن يتعرق المطور في لعبة Live-i18n ، أعتقد أن POC صغيرة الحجم لرجل واحد هي كمية صغيرة من العرق لتحقيق عائد هائل في شكل البصيرة ويمكن أن يتجنب دفع Live-i18n إلى عام 2020.

لم يتم الانتهاء من خدمة وقت التشغيل للمستخدمين الخارجيين حتى الآن ، لدينا فقط الكود الذي يستخدم الإغلاق ( goog.getMsg ) لأن هذا هو ما نحتاجه لاختبار Ivy مع تطبيقات Google.
سأعمل على هذا الآن للأشهر القادمة. هذا يعني أنه ربما لا يمكنك استخدام i18n مع Ivy حتى الآن.
تم دمج رمز وقت التشغيل i18n بالأمس للتو ، ويجب دمج رمز المترجم لـ i18n في الأيام القليلة المقبلة (سنصل إلى هناك!). ثم سنعمل على الخدمة الجديدة للأشخاص الخارجيين ، بما في ذلك اللوادر الجديدة التي تحدثت عنها أعلاه ، وخدمة استخدام الترجمات في التعليمات البرمجية الخاصة بك.

بالنسبة إلى تبديل اللغة على الفور ، فإنه لا يزال يتطلب إعادة تحميل كاملة للتطبيق ، أو ربما تغيير المسار (من شأنه تنظيف جميع المكونات الموجودة). لن أحاول العمل على POC حتى الآن.

بالنسبة إلى تبديل اللغة على الفور ، فإنه لا يزال يتطلب إعادة تحميل كاملة للتطبيق ، أو ربما تغيير المسار (من شأنه تنظيف جميع المكونات الموجودة). لن أحاول العمل على POC حتى الآن.

هذا عادل ، ... ومع ذلك لا يتطلب إعادة تحميل كاملة للتطبيق (أو أي شيء يحقق السلاسة في نظر المستخدم النهائي ، ولا تفقد AKA المتجر ، ولا المصادقة ، ولا عنوان url (حسنًا ... لا يمثل /en/... ) وكل ذلك ضمن مهلة معقولة) .... ما زالت الخطة صح؟

tatsujb لا يؤدي إعادة تحميل التطبيق إلى إعادة تحميل الصفحة ، حيث يعيد StackBlitz تحميل التطبيق عند كل تعديل ، هل تشعر أنه يمكن ملاحظته لعينيك؟

إعادة تحميل التطبيق يعني إلغاء تحميل التطبيق ثم تحميل التطبيق في نفس الموضع ، وهو ما يعادل انتقال SSR-CSR (إنه CSR-CSR) ، ويجب ألا تكون هناك مهام غير متزامنة في عملية التمهيد اللاحقة إذا تم النظر في بنية ذاكرة التخزين المؤقت المناسبة.

لذلك مع هذا الإعداد الصحيح ؛ تخزين القيم المتغيرة والمصادقة (وكذلك مقدار التمرير على divs القابلة للتمرير) ستبقى؟

tatsujb طالما تم تخزينها خارج مثيل تم إنشاؤه بواسطة Angular ، على سبيل المثال في المتغير المعجمي أو خاصية النافذة.

trotyl كيف تعيد تحميل التطبيق بدون الصفحة؟

saithis يمكنك دائمًا تشغيل التطبيق بواسطة platformBootstrap().bootstrapModuleFactory() (أو ما يعادله) بشكل إلزامي ، يمكنك تسميته في أي وقت في أي مكان ، ولا يوجد سحر عند الاتصال (باستثناء Angular CLI لديها حاليًا بعض القيود لاستبدال الكود ، يجب ألا تكون مشكلة في اللبلاب).

يعد Bootstrap بشغف في وقت استدعاء البرنامج النصي والاحتفاظ به إلى الأبد (لا تقم بإلغاء التحميل) مجرد ممارسة شائعة لـ SPA ، ولكن لا أحد يجبرك على القيام بذلك.

تحرير: في حالة قيام شخص ما بذلك ، فإنه يلزم أيضًا تدمير برنامج التمهيد NgModuleRef لمنع تسرب الذاكرة. هذه أسئلة خارج الموضوع ومن الأفضل مناقشتها في قناة أخرى ، من الأفضل متابعة مناقشة i18n هنا.

@ trotyl شكرًا ، لم أكن أعرف أن التمهيد يعمل مرة أخرى.

ocombe هل يمكنك من فضلك إزالة البريد العشوائي هنا؟ وتعليقي كذلك.

1. إلى fetis : يجب على الأشخاص أمثالك إلغاء متابعة المشكلة والاشتراك في الإصدار للإصدار
   

2. إلى Andrulko : نحن لا نهتم

3. إلى @ الزاوي: كما قال أنا أفهم تماما يشكو هنا! مثلما أردنا Ivy لـ v7 وليس لـ vX أو لا تبيع تحسينًا كبيرًا لـ v7 بينما لا يمكنك الرد عليه أو ستضعه في 7.x فقط احترامًا لموعدك النهائي ... هذا ليس عدلاً! يجب أن يكون خيار نعم هو عدم الإعلان عن أي شيء ولن يشكو أحد من أن هذه فكرة سيئة أيضًا ، فأنت بحاجة إلى جعل مكانك في إطار العمل. نعم ، نحن ننتظر i18n الصحيح منذ الإصدار 2 ، في هذا الجانب الإلزامي للتطبيق الكبير ، لا يمكنك بيع الزاوي جاهزًا لتطبيق كبير مثل تطبيق الويب الدولي الذي يحتوي على 50000 سلسلة ، بالطبع أنت بالتأكيد لا تحب قراءة هذا ولكنه بدون رحمة وبحسن الإيمان ، imho إذا لم نفكر في i18n ووقت البناء البطيء / وقت التطوير لجميع الجوانب الأخرى يمكنني القول أن الزاوي رائع. يجب أن يتغير اتجاه معين في الأعلى ، وأنا أتحدث إلى أصحاب القرار بالطبع. استثناء كبير منا (الذي ينتقد) لأنه من Google الكبيرة لم نتمكن من ارتكاب خطأ كبير مثل هذا. أرى مطوري Google مثل الاستثناءات - الأشخاص الأذكياء دون أخطاء يجب ألا تحدث هذه الأشياء للمطورين ذوي الخبرة و devteam مثل Google! رأيي العالمي لا يبيع الزاوي بنسبة 100٪ للتطبيقات الكبيرة عندما تختاره الشركة ثم تبيع / تشرح الشركة الخاصة ما هو المصدر المفتوح!

4. @ الكل خاصة بالنسبة لأولئك الذين لا يعملون في شركة تجارية: يكرهون مجيئي لأنني بالتأكيد لا أحترم المصدر المفتوح؟!؟! ، لول اذهب قل هذا إلى رئيسي في الانتظار .. انتظر ... إنه جاهز (100٪ وليس 80٪) للتطبيق الكبير ... نحن نعتمد!

هذا تعليقي الأخير هنا لأننا تركنا السفينة! إلغاء الاشتراك + عدم اختيار الزاوية في مشروعي التالي (يمكنك القول أنك الفائز ، ومشروع مفتوح المصدر لا يحتاج إلى أشخاص مثلنا)

هذا الشغف! فقط لتحقيق التوازن ... أعدنا كتابة تطبيقنا في Angular 6 ، والذي تم تدويله بست لغات ، وشعرنا فقط بإزعاج بسيط. بالتأكيد ، ستكون أوقات الإنشاء والترجمات الأسرع أثناء التنقل أمرًا رائعًا بالتأكيد ولكنها لن تكون نهاية العالم بالنسبة لنا. 98٪ من إطار العمل غير i18n رائع. عمل رائع يا رفاق! نتطلع إلى الميزات الجديدة.

لدينا أيضًا تجربة رائعة مع Angular لبوابة مؤسستنا الجديدة. i18n هي آخر ميزة مفقودة نحتاج إليها ، حيث يتعين علينا في سويسرا دعم أربع لغات. أعتقد أن القضية هنا تتعلق بالتواصل. بالنسبة لتخطيط المشروع ، إذا كان لدينا تقدير أفضل لإصدار i18 قبل عام ، كان بإمكاننا التخطيط له والنظر في الاحتمالات الأخرى. ومع ذلك ، فإننا نتطلع إلى سماع أي تحديثات. :-)

دفاعًا عن الزاوي ، يمكنك استخدامه ببساطة كافية في إنتاج مثل هذا (أفضل حل وجدته)

1. قم بلف نص متغير مترجم في المكون الخاص لنقل منطق الترجمة إلى مكان ما

parent-component.component.html

<app-route-translation
  [routeData]="routeData"
></app-route-translation>

route-translation.component.html

<span
  i18n="route text|Navigation text for route@@routeText"
>{
  routeData.langKey, select,

  home-1 {Home 1}
  home-1-1 {Home 1-1}
  home-1-2 {Home 1-2}
  home-2 {Home 2}
  home-2-1 {Home 2-1}
  home-2-2 {Home 2-2}
  home-root {Home root}
  lazyPage {Lazy page}
  notFound {404}

  other {Other}
}</span>

1. قم بتكوين مجلدات تكوين البناء في angular.json like

"prod-en": {
  ...
   "outputPath": "dist/en/",
  ...
},
"prod-ru": {
  ...
   "outputPath": "dist/ru/",
  ...
}

1. قم بتكوين ملف بناء docker مثل هذا لترجمة التطبيق للغات مختلفة

FROM node:8 as build-stage
WORKDIR /app
COPY angular-util .
RUN npm install
RUN npm run ng build -- --configuration=prod-en
RUN npm run ng build -- --configuration=prod-ru

FROM nginx
WORKDIR /usr/share/nginx/html
COPY --from=build-stage /app/dist .
COPY nginx.conf /etc/nginx/conf.d/default.conf

1. استخدم nginx.conf هذا لخدمة التطبيق على المجالات الفرعية (مثل en.site-name.com ، ru.site-name.com) ، حيث يجب استبدال ru في set $subdomain ru; بالإعدادات المحلية الافتراضية

server {
  listen 80;
  set $subdomain ru;
  if ($host ~ ^(\w+)\.) {
    set $subdomain $1;
  }
  location / {
    root /usr/share/nginx/html/$subdomain;
    try_files $uri $uri/ /index.html =404;
  }
}

لمزيد من التفاصيل انظر هنا
https://github.com/ivanivanyuk1993/angular-util/tree/master/src/app/util/shared/route-list
https://github.com/ivanivanyuk1993/titans-shoulders-project/tree/master/container-description/ui-container-description

أود الحصول على إبهام لهذا التعليق. قد لا يكون الأمر مثاليًا ، لكنه لا يزال أكثر مشاركة مفيدة حول هذا الموضوع الذي وجدته على الويب

مرحبا بالجميع،

أنا أستخدم ترجمات i18n لمشروعي. لدي شك في المجال التالي:

1. هل من الممكن إنشاء ملفات مصدر xlf مختلفة لمكتبات مختلفة (تم إنشاؤها باستخدام أمر ng إنشاء مكتبة اسم المكتبة)؟
2. أثناء استخدام التدويل للاختيار أو الجمع ، ينشئ ملف مصدر xlf الذي تم إنشاؤه معرف الوحدة العابرة للبدائل المختلفة. هل من الممكن توفير معرف عبر نموذج لبدائل مختلفة أيضًا؟ (كما هو موضح في الصورة أدناه)
   

من فضلك ، هل يمكنك مساعدتي ببعض الإجابات.

learnersLicense :

1. يجب أن تكون قادرًا على استخراج ملف ترجمة واحد لكل مشروع يتعامل معه cli. يقال إن الترجمات لا تعمل مع المكتبات في الوقت الحالي (بمعنى أن الشخص الذي يستهلك مكتبتك لن يتمكن من تحميل ترجماتك لتلك المكتبة). إنه على رأس قائمة المهام الخاصة بنا لمعرفة الميزات التالية التي سنقوم بتنفيذها (مع ترجمات الكود)

1. لا أعتقد أن هذا ممكن. يمكنك تسمية العناصر النائبة بتعليقات خاصة: <div i18n>Some value: {{ valueA // i18n(ph="PH_A") }}</div> لكنني لا أعتقد أنها تعمل مع تعبيرات وحدة العناية المركزة ، AndrewKushnir ؟
   يمكنك تقديم طلب ميزة لذلك ، أو ربما إضافة تعليق إلى https://github.com/angular/angular/issues/24080 والذي يبدو مشابهًا (أضف وصفًا / معنى لتعبيرات وحدة العناية المركزة)

لن يتمكن أي شخص يستهلك مكتبتك من تحميل ترجماتك لتلك المكتبة

طريقة واحدة لحل هذا هو:
1) لديك مكتبة استخراج i18n إلى xliff وترجمتها
2) شحن ملفات xliff مع حزمة المكتبة

3) يقوم المستهلك أيضًا باستخراج ملفات xliff الخاصة به
4) أحمال المستهلك xliff إلى المحلل اللغوي xml. يسقط أي وحدات عابرة تنشأ من node_modules
5) concats المستهلك هو xliff مع مكتبة xliff

مما يعني أن الشخص الذي يستهلك مكتبتك لن يتمكن من تحميل ترجماتك لتلك المكتبة

ربما أسيء فهم هذا البيان ولكني أعلم أنه من خلال إعداد الترجمات لتطبيقات شركتي عندما أقوم بإنشاء ملفات xlf الخاصة بي ، فإنها تتضمن مفاتيح محددة في قوالب المشاريع الأخرى. واحد يتبادر إلى الذهن هو https://github.com/ng-bootstrap/ng-bootstrap

لا يبدو هذا ممكنًا في الوقت الحالي:

<my-button i18n-title="@@SHARED_GO_LABEL" [title]="'Go'" [button-style]="'primary'" (click)="navigateToForm()"></my-button>

في نطاق هذه التغييرات ، هل ستتم معالجة ذلك (أم أفعل شيئًا خاطئًا)؟

mikejr83

هذا محتمل. عليك فقط تعيين القيمة الأساسية لـ title كـ title="Go" وليس [title]="'Go'"

شكرًا لك ocombe و @ ewok-janitor على إجاباتك واقتراحاتك. 👍

ocombe هل هناك أي تاريخ مؤقت قبل توفر ترجمات للمكتبة؟

لا يوجد تاريخ الآن. بالنسبة للإصدار الأول من Ivy ، نحاول فقط الحصول على ميزة التكافؤ. سنعمل على الميزات الجديدة (بما في ذلك ترجمة الشفرات ودعم المكتبة) مباشرة بعد ذلك (أو سنبدأ في الواقع في العمل عليها من قبل ، ولكن لن يتم الانتهاء منها عندما يتم إصدار Ivy في إصدار ألفا). سيكون متاحًا قبل أن يصبح Ivy هو الخيار الافتراضي.

هل يوجد بالفعل إصلاح لملفات xliff؟ https://github.com/angular/angular/issues/17506
من المستحيل استخدام التنسيق على الإطلاق طالما لم يتم إصلاح المراجع.

ocombe أية خطط لدعم ترجمة المسارات؟

لقد تم طلبها عدة مرات ، نعم ، إنها ليست خطة فورية ولكنها مدرجة في قائمة الأشياء التي يجب القيام بها

مرحبًا ، هل هناك أي وثائق حول كيفية استخدام وقت التشغيل i18n عند إصدار Ivy في الإصدار التجريبي؟

marcelnem ، إذا قمت بفحص عنوان URL هذا ، فإن جميع نقاط التوثيق معلقة.

https://is-angular-ivy-ready.firebaseapp.com/#/status

ocombe عمل رائع تقوم به في Google الآن. يجب أن يكون Angular i18n "شيئًا" مثل ngx-translate من البداية. كنت أتساءل عما إذا كان سيكون هناك دليل ترحيل ، أداة آلية ، مقارنة الميزات ، ... للانتقال من ngx-translate إلى Angular i18n style بمجرد إصدار Angular 8/9؟

مرحبا اومبي
تحتاج إلى التحقق معك بخصوص هذه الميزة ، الميزة التي ذكرتها أعلاه
وقت التشغيل i18n (حزمة واحدة لجميع اللغات مع AOT) - [جارٍ العمل عليها] >> هل هذا لا يزال قيد التقدم ، أم أنه خارج

هل يمكنك إخباري ، بأي حل ، إذا كان لا يزال قيد التقدم
شكرا لك

ocombe الذي كتبته أعلاه أنه يجب تحميل حزم اللغة عن طريق التحميل اللاسي. هل يمكن أيضًا تحميل حزم اللغات مباشرة في index.html؟ لأن لدينا حالة أن تطبيقنا يعمل عبر AWS Lambda ويتم تخزين الملفات الزاوية المترجمة في حاوية S3. إنه بالفعل حل بديل يعمل على الإطلاق ، لكن لا يمكننا استخدام التحميل اللاسي لأن Angular لا يمكنه تحميل الملفات من مضيف آخر. لذلك ، يجب تضمين جميع الملفات التي يحتاجها Angular بالفعل في index.html (حيث نضيف مضيف S3 عبر برنامج نصي).

@ nidhi8953 لا يزال العمل قيد التقدم ، وسيكون متاحًا مع Ivy ، في الوقت الحالي يعمل فقط داخل google (لأننا نستخدم Closure Compiler داخليًا للترجمات). خدمة وقت التشغيل التي ستتولى الترجمات هي خدمة تجريبية جدًا للعالم الخارجي. إذا كنت ترغب في اختبار بعض الأشياء ، فيمكنك إلقاء نظرة على هذا المثال: https://github.com/angular/angular/blob/master/packages/core/test/bundling/hello_world_i18n/index.ts ولكن يجب أن تعرف ذلك لا تزال الوظائف خاصة لسبب ما ، سيتم إعادة تسميتها وتغييرها في المستقبل القريب جدًا. الهدف الحالي هو بدء العمل على مجموعة صلبة من واجهات برمجة التطبيقات بمجرد خروج الإصدار 8 (في نهاية الشهر) والتكرار حول هذا الأمر على مدار الإصدار 8 بالكامل حتى يتم إيقاف الإصدار 9 ، وعند هذه النقطة يجب اعتبار واجهة برمجة التطبيقات مستقرة

vekunz إذا اتبعنا خططنا الحالية ، فمن الممكن أن يكون ذلك ممكنًا ، نظرًا لأنك تحتاج إلى تحميل ملف الترجمة في تمهيد التطبيق الخاص بك على أي حال

ocombe هل يمكننا استخدام Ivy (حاليًا 8.0.0-rc.3) وتنفيذ i18n باستخدام طريقة Angular 7 للبنيات المتعددة؟ أو هل أحتاج إلى الالتزام بـ Angular 7 حتى يتم تحرير i18n APIs لـ Ivy؟ إذا أمكن ، أود حقًا الاستفادة من Ivy ، بينما في نفس الوقت أستخدم الطريقة القديمة لـ i18n حتى تتوفر طريقة وقت التشغيل الجديدة.

تحديث: بعد تجربته ، لا يوجد أي تأثير لاستخراج ng xi18n (راجع #https: //github.com/angular/angular-cli/issues/14225) أو بناء w / i18n. لا يتم تصدير ملف xlf ولا توجد كلمات مترجمة. ولكن مع ضبط الخيار enableIvy على false في tsconfig.app.json ، يعمل كلاهما بشكل رائع مع الإصدار 8.0.0-rc.3. هذا يعني أنه يمكنني اتباع مسار ترقية Angular ، وعدم فقدان i18n ، والحصول على بعض المزايا الجديدة مثل التحميل التفاضلي ، والاستعداد لتشغيل Ivy بمجرد تشغيل i18n.

jacobbowdoin كما اكتشفت أنه لا يعمل مع Ivy ، ولكنه يعمل إذا لم يتم تنشيطه.
كنت أرغب في جعل نظام الاستخراج / التحميل القديم يعمل مع Ivy ، ولكن نظرًا لأنه سيكون مؤقتًا ، لم يتم تحديده كأولوية من قبل الفريق (وهو أمر مفهوم ، فإن جعل الأشياء الإلزامية تعمل أولاً هو الأولوية).

مرحبًا ocombe ، نريد تطوير i18n الآن ، لذلك لا يمكننا انتظار وقت التشغيل i18n. هل ما زلت توصي باستخدام ترجمة ngx؟ هل يعقل استخدامه مع i18n-polyfill؟ هل سيؤدي استخدام i18n-polyfill إلى تسهيل الترحيل إلى وقت التشغيل i18n؟

إذا كنت تستخدم ngx-translate ، فلا تستخدم i18n-polyfill. من المنطقي استخدامه فقط إذا كنت تستخدم الزاوية i18n للقوالب.
ngx-translate لا يزال ملائمًا وسهل الاستخدام. لا يتعين عليك وضع كل البنية التحتية في مكانها لدعم إنشاءات متعددة (واحد لكل لغة).

مرحبًا ocombe ، هل هناك أي تحديث للحالة على:

وقت التشغيل i18n
-استخدام سلاسل الترجمة خارج النموذج - # 11405

نحن نناقش حاليًا ما إذا كان يجب علينا انتظار ترجمات الكود المصدري أو استخدام i18n-polyfill (بدأنا بالفعل بـ i18n). يمكننا بسهولة الانتظار لبضعة أسابيع ، لذلك سيكون موضع تقدير جدول زمني تقريبي. شكرا جزيلا!

halilovicedvin بمجرد أن يكون Ivy هو الخيار الافتراضي في تطبيقات Google ، سنبدأ العمل على خدمة وقت التشغيل i18n للمستخدمين الخارجيين ، لذلك في مكان ما بين قريبًا و v9
لن أعتمد عليه إلا بعد الصيف لأن الناس سيأخذون إجازة لبضعة أيام

halilovicedvin بدأنا مع i18n مع i18n-polyfill منذ بضعة أسابيع وهو يعمل بشكل رائع. آمل أن يتم استخدام runtime-i18n بنفس طريقة استخدام i18n-polyfill

vekunz كنت آمل أيضًا أنه إذا استخدمنا ngx-translate مع i18n-polyfill ، فسنكون قادرين على الترحيل بسهولة إلى وقت التشغيل-i18n ولكن بعد التعليق من ocombe (https://github.com/angular/angular/issues / 16477 # issuecomment-498239301) لست متأكدًا مما إذا كان الجهد الإضافي لإعداد polyfill له ما يبرره. ربما نستخدم فقط ترجمة ngx.

vekunz ما هي تجربتك في إعداده؟

marcelnem لا يمكنك استخدام ngx-translate مع i18n-polyfill. i18n-polyfill مخصص للاستخدام فقط مع angular-i18n.

كان إعداد i18n-polyfill سهلاً للغاية حقًا. حتى التوثيق ليس صحيحًا تمامًا ، فقد اكتشفت أنه سريع جدًا ما يجب تغييره.

vekunz أفهم الآن ، شكرا لك. لست متأكدًا من الغرض من i18n-polyfill. هل لا يزال يتعين عليك إنشاء التطبيق عدة مرات ونشره عدة مرات ضمن http: // myapp / en ، http: // myapp / de ، http: // myapp / fr ، ... كما هو الحال مع الزاوية الرسمية i18n؟

marcelnem نعم ، أنت بحاجة إلى إنشاءات متعددة باستخدام i18n-polyfill أيضًا. الغرض من ذلك هو أنه باستخدام angular-i18n ، يمكنك استخدام الترجمات حاليًا داخل قوالب html فقط وليس داخل كود الكتابة المطبوعة. يمتد i18n-polyfill إلى angular-i18n لاستخدام الترجمات داخل كود الكتابة المطبوعة أيضًا.
مع Angular 9 (في الخريف) ، ستدعم Angular-i18n الترجمات داخل الكتابة المطبوعة أيضًا ، ولكن في هذه الأثناء نحتاج إلى i18n-polyfill لهذا الغرض.

vekunz ، هل يمكنك أن تذهب إلى مزيد من التفاصيل حول هذا الأمر: "حتى الوثائق ليست صحيحة تمامًا ، فقد اكتشفت أنها سريعة جدًا ما يجب تغييره." من المحتمل أن أبحث في i18n-polyfill الأسبوع المقبل ، لذا فإن أي معلومات ستكون مقدرة. شكرا

halilovicedvinmarcelnem لقد أنشأت مستند لصق حيث أصفه ، لأنه ليس الموضوع الرئيسي لمشكلة GitHub هذه https://pastebin.com/Xib6X6E9

ocombe باستخدام أداة xi18n ، هل يمكنني تقييد مسار الإدخال إلى مجلد src فقط (لإنشاء الترجمات) بدلاً من المشروع / المستودع بأكمله؟

ocombe هل يدعم Ivy لغات متعددة باستخدام Angular 8 (فقط تعريف اللغة وليس ملف اللغة ؛ على سبيل المثال أنابيب التاريخ)؟ نظرًا لأن فريقًا آخر يستخدم Angular حاليًا مع ترجمة ngx ، إلا أن مكونًا تابعًا لجهة خارجية يحتاج إلى الإعدادات المحلية الصحيحة. قد يكون أحد الخيارات هو استخدام مترجم JIT في وضع prod ، لكن هذا ليس جيدًا جدًا. لكنهم أيضًا لا يستطيعون تجميع حزمة جديدة لكل لغة ، لأن هذا سيكون كثيرًا جدًا.

vekunz لا ، لا يمكنك تعيين لغات متعددة ، تحتاج إلى تعيين الإعدادات المحلية لكل حزمة مجمعة (يمكن تعيينها في ملف التكوين cli)
أعلم أن هذا ليس ما تريد سماعه ، ولكن هذا ما هو عليه الآن

ocombe هل يمكنك إخبار شيء ما ، أعلم أن فريق Angular لا يعرّفها على أنها مشكلة ، لكن هل تعتقد أن Angular سيسمح لنا في المستقبل المنظور بتغيير اللغة في وقت التشغيل دون إعادة تحميل التطبيق ، لذا فإن الحصول على الترجمة بلغة حزمة واحدة وإمكانية تحميل الترجمات الصحيحة وربطها بالنصوص الحرفية؟

وجود حزمة واحدة نعم ، ولكن سيتم تحميل الترجمات في boostrap (عند تحميل التطبيق). مع الهيكل الحالي ، سيكون من الصعب جدًا إعادة تحميل الترجمات "بشكل سريع" دون إعادة تحميل المكونات التي تستخدم الترجمات بالفعل.
أنا لا أقول أن هذا مستحيل ، لكن لسوء الحظ لا أتوقع حدوثه في المستقبل المنظور.

شكرًا ocombe على الاستجابة السريعة :) استمر في العمل الجيد: +1:

كان هناك في مكان ما عرض تقديمي لـ ocombe من مؤتمر زاوية (أعتقد AngularConnect) حيث تحدث عن i18n و Ivy ، وهناك وصفه جيدًا جدًا ، لماذا هذا معقد للغاية. يمكنني محاولة العثور على الفيديو.

أعتقد أنني وجدته https://www.youtube.com/watch؟v=miG-ghJhFPc

بالنسبة للأشخاص الذين ينتظرون وقت تشغيل i18n مع Ivy ، فإن الخطة الحالية لـ v9 هي الحصول على ترجمات تعمل مع Ivy ولكن فقط كخطوة بناء (كما هو الحال الآن مع محرك العرض). هذا يعني أنه سيظل بناء / لغة واحدة في الوقت الحالي ، ولن تكون هناك ترجمات للأكواد (ترجمات القوالب فقط).

المشكله. حسنًا ، على ما يستحق ، شكرًا على عملك الشاق!

ocombe هل ستستمر في الحفاظ على polyfill لترجمات التعليمات البرمجية لوقت التشغيل؟

إذا تعطلت نعم ، فلن أقوم بإضافة أشياء جديدة إليها بالرغم من ذلك

إنه لأمر مزعج أن i18n كان مواطنًا من الدرجة الثانية لفترة طويلة ... لا يعمل الجميع في بيئة لغة إنجليزية الأم. ):

حسنًا ، أوافق ، أحاول العثور على بعض الشركات التي ترعاني حتى أتمكن من تطوير حلول i18n قوية جديدة لـ Angular (لدي الكثير من الأفكار).
إذا كنت تفكر في الأشخاص المهتمين ، فأخبرني على Twitter (ocombe) أو عبر البريد الإلكتروني ([email protected]) 🙂

ocombe أود أن أشكرك على عملك أيضًا. 💚 إنه لأخبار مفاجئة بعض الشيء أن عليك مغادرة الفريق. كما قلت I had to ... ، فإنه يرشدني إلى أن أسألك مباشرة عن السبب الرئيسي. أنا أكره تلك التلميحات والتخمينات غير المباشرة ، ولهذا السبب مثل هذا السؤال المباشر لك.

كنت مقاولًا خارجيًا أعمل مع فريق Angular ولست موظفًا بدوام كامل في Google ، وبالتالي يمكن أن ينتهي عقدي في أي وقت بناءً على ما يحتاجه الفريق.
إنهم يجندون أشخاصًا جددًا داخليًا للمساعدة في المشروع وأنا واثق من أنهم سيجدون الأشخاص المناسبين للمساعدة في i18n ومواضيع أخرى ، لذلك لا داعي للقلق بشأن مستقبل Angular: visage_légèrement_souriant: إنه مجرد نكسة مؤقتة

ocombe شكرًا لك على التوضيح.

هل يمكن لأي شخص أن يخبرني كيف يمكنني استخدام i18n (i18n-polyfill) خارج الفصل مثل التعدادات أو المصفوفات الثابتة أو شيء مثل ملفات .model.ts؟

بالنسبة للثوابت ، ما زلت أضعها في الفصل. لا أعرف أي بديل: /

ocombe شكرًا جزيلاً على عملك الشاق مع i18n لـ Angular مع ngx-translate و i18npolyfill ومع فريق Angular.
نحن نستخدم عملك يوميًا لتقديم ترجمات لمستخدمينا ، كما هو مطلوب من قبل أي تطبيق غير تافه.
أتمنى لك التوفيق فيما تفعله للمضي قدمًا.

بالنسبة للثوابت ، ما زلت أضعها في الفصل. لا أعرف أي بديل: /

حسنًا .. إذا قمت بنقلهم إلى الفصل ، فأنا بحاجة إلى جعل المتغير ثابتًا لاستخدامه. لكن لا يمكنني استخدام i18n لمتغير ثابت.

مثال على فئة التصدير {
مُنشئ (خاص i18n: I18n) {}
متغير ثابت = i18n ('نص') ؛ // لا يمكنني استخدام i18n هنا لأنه غير ثابت لمثال فئة
}

خبر محزن ... هذا "يضعف" Angular ... كما يقول الآخرون ، يبقى فقط الشكر الكبير لـ ocombe على العمل الرائع ، حظًا سعيدًا!

لدي فضول ، ما هي عيوب استخدام ترجمة ngx؟ يبدو أنه قادر بالضبط على الوظيفة التي يبحث عنها الناس

أود أن أقول إن المساوئ هي التالية:

• يزيد من حجم الحزمة (lib + خارجي ترجمات كملفات خارجية بدلاً من استبدال الكود في وقت البناء)
• ليس رسميًا (إذا مت ، فسيتم إيقاف lib ، وليس نفس المستوى من الدعم)
• لا يدعم xliff / xmb (ولكنه يدعم json والتنسيقات الأخرى عبر المكونات الإضافية ، ويمكن للمرء إنشاء مكون إضافي xliff / xmb لدعمه)
• قد يكون هناك بعض سلوكيات عربات التي تجرها الدواب عند التحميل البطيء / تقسيم الترجمات (لم أتمكن مطلقًا من إصلاح ذلك)
• بناء الجملة أكثر تعقيدًا مقارنة بالتنفيذ الرسمي
• الأداء (التحميل الأولي للترجمات يمكن أن يجعل النص يختفي لمدة ثانية واحدة ، والمزيد من ضغط الذاكرة لأنني يجب أن أراقب المحتوى في وقت التشغيل لمعرفة ما إذا كان هناك شيء قد تغير)

يقال أنه يبدو جيدًا بما يكفي لكثير من الأشخاص

من الغريب كيف تروج شركة Angular لإمكانية الوصول وتستثمر فيها ولكنها لا تتضمن لغات في تلك الحزمة. إنه شعور حقًا أن هذا قرار تم اتخاذه من بيئة أحادية اللغة.

قادمًا من بيئة يتعين علينا فيها عادةً تقديم 3-4 لغات بالتبادل ، كنت أنتظر بصبر إصدار هذه الميزة منذ إعلانها بمزاياها الواضحة على استخدام مكتبة خارجية. مع هذه الأخبار ، سيتعين علي إعادة النظر في استراتيجيتنا لإدارة الترجمات بالكامل.

ocombe ألا توجد فرصة في أن تقوم Google بتعيينك لست مقاولًا؟ 😉

DmitryEfimenko نحن نستخدم ngx-translate حاليًا ونحن سعداء جدًا به.

ocombe ما هي فرصة قبول Google لهذه الميزة من مطور / مجتمع خارجي؟ أعتقد أننا ننتظر طويلاً جدًا.

إذا كنت جادًا في التعامل معها وترغب في قضاء بعض الوقت في العمل عليها ، فأنا أقول إن هناك احتمالات كبيرة بقبولهم للمساعدة في العمل على هذه الميزة

إذا كنت جادًا في التعامل معها وترغب في قضاء بعض الوقت في العمل عليها ، فأنا أقول إن هناك احتمالات كبيرة بقبولهم للمساعدة في العمل على هذه الميزة

ocombeIgorMinar أود تقديم بعض الأعمال التطوعية لـ Ivy i18n ، يرجى إعلامي إذا كانت هناك بعض الفرص.

إذا كنت جادًا في التعامل معها وترغب في قضاء بعض الوقت في العمل عليها ، فأنا أقول إن هناك احتمالات كبيرة بقبولهم للمساعدة في العمل على هذه الميزة

أنا على استعداد للمساهمة ولكني لا أعرف على الإطلاق نطاق وتعقيد المهام. هل يمكننا أخذ القائمة في الرسالة الأصلية كمواصفات / متطلبات لدينا؟

لا ، هذه القائمة عفا عليها الزمن الآن.
سأخبر الفريق بأنكما مهتمتان حتى نتمكن من معرفة كيفية تنظيم ذلك.

ocombe أعتقد أنه أكثر من 2 منا.

ما نحتاجه من فرق Angular هو

• قائمة المتطلبات / بعض المواصفات
• تقدير التعقيد التقريبي
• 1-2 مرشدين للتواصل

مع هذا المجتمع يمكن تنظيم التطوير وتقسيم المهام

هناك ما أعلم به في https://hackmd.io/UfFN_wyVT-Ob1p70nA3N_Q ؟

fetis قد لا تكون فكرة جيدة أن يتم تقسيم العمل كثيرًا ، كما أن تكلفة الاتصال ومشاركة السياق باهظة أيضًا ، خاصة بالنسبة لبعض الأعمال الأساسية التي لديها فرصة كبيرة للتعارض.

ما زلت متفاجئًا من أن XLIFF مدرج كمحترف (أو بالأحرى ، فإن عدم وجود ترجمة لـ ngx-translate يعد خداعًا). يبدو أن ترجمة Google وخدمات Google الأخرى تستخدم ملفات ARB ، وهو تمثيل JSON لسلاسل الترجمة. على سبيل المثال ، قمنا ببناء تطبيقات الأجهزة المحمولة الخاصة بنا باستخدام Flutter / Dart ، حيث يتم تنفيذ INTL مع ملفات ARB. سيكون من الجيد أن يأخذ فريق Angular ، عند النظر في هذا الأمر ، هذا في الاعتبار لتحسين التفاعل مع العناصر الأخرى في نظام Google البيئي.

قد لا تكون فكرة جيدة تقسيم العمل كثيرًا ، كما أن تكلفة الاتصال ومشاركة السياق باهظة أيضًا ، خاصة بالنسبة لبعض الأعمال الأساسية التي لديها فرصة كبيرة للتعارض.

أوافق ولكن لا أعتقد أن هذا كله يمكن أن يسلمه شخص واحد في وقت معقول. النطاق ضخم جدًا

قد لا تكون فكرة جيدة تقسيم العمل كثيرًا ، كما أن تكلفة الاتصال ومشاركة السياق باهظة أيضًا ، خاصة بالنسبة لبعض الأعمال الأساسية التي لديها فرصة كبيرة للتعارض.

أوافق ولكن لا أعتقد أن هذا كله يمكن أن يسلمه شخص واحد في وقت معقول. النطاق ضخم جدًا

fetis يمكنني العمل معك. نريد حقًا استخدام الزاوية i18n في مشاريعنا ، لكنها محدودة للغاية.

سأخبر الفريق بأنكما مهتمتان حتى نتمكن من معرفة كيفية تنظيم ذلك.

ocombe أي ملاحظات من فريق Angular؟

لقد أخبرتهم بذلك وبدوا مهتمين ، لكنهم بحاجة إلى وضع خطة ملموسة لكل ذلك قبل أن يتمكنوا من قبول المساعدة الخارجية (وإلا فلن تعمل على ما هو مطلوب).
petebacondarwin سيتولى المسؤولية من الآن فصاعدًا

مرحبًا ocombe ، كنت أتصفح التعليقات وأدركت تقريبًا أنه لا يوجد شرط لإنشاء معرفات ديناميكية لعلامة i18n أثناء استخدامها في * ngFor. هل هناك أي خيار آخر أو حل بديل؟ أو لا بد لي من استخدام ترجمة ngx فقط.

swapnilvaidankar لا أعتقد أن هناك حلًا ، لا

swapnilvaidankar - هل يمكنك شرح ما تقصده بهذا؟

إنشاء معرفات ديناميكية لعلامة i18n أثناء استخدامها في * ngFor

كما نعلم ، لترجمة النص الثابت إلى أي لغة أخرى ، يتعين علينا استخدام سمة i18n في علامة عنصر HTML على النحو التالي ،

<h1 i18n = "Card Header | Title for the under construction card@@constructionheader">Under Construction</h1>

الذي يولد مقتطف ملف xlf على النحو التالي ويمكننا تحديد الهدف لأي لغة. هنا قمت بالترجمة للفرنسية على النحو التالي ،

  <trans-unit id="constructionheader" datatype="html">
    <source>Under Construction</source>
    <target>En construction</target>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/app.component.html</context>
      <context context-type="linenumber">3</context>
    </context-group>
    <note priority="1" from="description"> Title for the under construction card</note>
    <note priority="1" from="meaning">Card Header </note>
  </trans-unit>

ولكن في حالة القائمة المنسدلة ، يبدو من الصعب استخدام سمة i18n.
على سبيل المثال ، إذا كنت أرغب في عرض قائمة المنتجات مثل بطاقة العمل والنشرات والكتيبات في القائمة المنسدلة أو القائمة البسيطة ، فكيف يمكنني إنشاء المعرف الديناميكي لـومن ثم يمكنني ترجمة أسماء المنتجات إلى الفرنسية أو أي لغة أخرى.

لقد حاولت بهذه الطريقة ،

• 
  {{ المنتوج }}
  

الذي ينشئ مقتطف ملف xlf على النحو التالي ولست متأكدًا من كيفية استخدام هذا لترجمة اسم المنتج إلى لغات أخرى باستخدامبطاقة شعار

  <trans-unit id="product" datatype="html">
    <source><x id="INTERPOLATION" equiv-text="{{ product }}"/></source>
    <context-group purpose="location">
      <context context-type="sourcefile">src/app/product/product.component.html</context>
      <context context-type="linenumber">6</context>
    </context-group>
    <note priority="1" from="description"> product name from List</note>
    <note priority="1" from="meaning">product name </note>
  </trans-unit>

المشكلة هنا ، إذا كان يمكنك رؤية المعرف فيالعلامة هي "المنتج" فقط. ومع ذلك كنت أتوقع أن يتم إنشاء المعرفات ديناميكيًا وفقًا لقائمة المنتجات التي ستكون متاحة في القائمة المنسدلة.

لست متأكدًا من كيفية تحقيق ذلك عند التعامل مع محتوى ديناميكي أو قائمة محتوى.

آسف للتفسير الشامل.
آمل أن تكون قد فهمت المشكلة هنا.

شكرا،
سوابنيل

هل يمكنك فتح قضية لذلك من فضلك؟ إنه ليس الموضوع هنا حقًا وإذا كان أي شخص آخر يبحث عن نفس الشيء فسيكون من الأسهل العثور عليه

سمات swapnilvaidankar i18n مخصصة لترجمة النص الثابت وليس المحتوى الديناميكي. في المثال الخاص بك ، تكون "المنتجات" إما قادمة من شفرة المصدر (محددة في ملف ts الخاص بك) وتحتاج إلى استخدام ngx-translate (أو ترجمة أسماء المنتجات مباشرةً في ملف ts) ، أو أنها تأتي من طلب Http ثم يجب توفير أسماء المنتجات المترجمة من خلال الواجهة الخلفية الخاصة بك.

لا أعتقد أننا بحاجة إلى إصدار جديد لذلك. إنه مجرد طلب للحصول على ترجمات وقت التشغيل في ملفات TS التي تم طلبها عدة مرات بالفعل.

swapnilvaidankar إذا كان عدد الخيارات محدودًا وأنت تعرفه بالفعل ، يمكنك إنشاء مكون بسيط باستخدام ngSwitch الذي يعرض النص. نحن نستخدم هذا الحل ، يعمل مثل السحر.

fetis - تكمن المشكلة في أنه من السهل جدًا تتبع هذه المشكلات العامة في المناقشات حول أشياء محددة. يوفر إنشاء عدد جديد موضوعًا جديدًا لمواصلة تلك المناقشة دون تشتيت انتباه هذا الموضوع.

fetis نعم ، لقد رأيت هذه المشكلة عدة مرات ولكن لم أجد أي حل مناسب. لقد جئت عبر ngSwitch أيضًا ولكن ليس الحل المناسب في حالتي. ومع ذلك شكرا على الحل.

ocombe أعتقد أنني بحاجة إلى نشر هذا كقضية في مكان آخر لمناقشة الأمر نفسه بدلاً من هنا. 👍

شكرا لكم جميعا على الردود.

petebacondarwinswapnilvaidankar ها هي المشكلة https://github.com/angular/angular/issues/11405 التي تبحث عنها
منذ 2.0.0-rc.6 (!) راجع للشغل

مرحبًا ocombe ، هل ما زالت هذه المشكلة محدثة؟ يبدو أن Ivy سيكون الخيار الافتراضي في Angular 9 ، لذا أتساءل ما هي حالة i18n؟ هل يمكنك من فضلك تقدير متى يمكن أن يكون جاهزًا للإنتاج؟ مع Angular 9 ، 10 ، 11؟ إذا لم يكن الأمر كذلك مع Angular 9 ، فهل ستشحن Angular 9 (و Ivy) بدون i18n أم أنها ستستخدم i18n القديم؟

يمكن العثور على مزيد من المعلومات حول الحالة الحالية في هذه المشكلة (https://github.com/angular/angular/issues/11405). تعليقات تستحق القراءة في هذا العدد حول الوضع الحالي:

• https://github.com/angular/angular/issues/16477#issuecomment -512290696
• https://github.com/angular/angular/issues/16477#issuecomment -506378004
• https://github.com/angular/angular/issues/16477#issuecomment -512548506

أيضا هذا يستحق التدقيق.

على الرغم من أننا نقلب المفتاح في الإصدار 9 بحيث يكون الوضع الافتراضي هو استخدام Ivy ، إلا أننا نتوقع أنه قد يكون هناك عدد من السيناريوهات التي لا تعمل بشكل كامل ، وأن هذه المشاريع ستلتزم بمحرك العرض في الوقت الحالي.
نحن نعمل على تشغيل i18n لإصدار v9.0.0 ولكنه سيكون ضيقًا.

ما هي الحالة الحالية على "Runtime i18n (حزمة واحدة لجميع اللغات)"؟

Ivajkin - آسف لعدم تحديث هذه المشكلة.

"Runtime i18n" هي ميزة مطلوبة بشكل شائع ولكنها قد تعني أشياء مختلفة لأشخاص مختلفين.
في أسلوب i18n $localize الجديد ، سيكون من الممكن القيام بالترجمة الفعلية في وقت التشغيل.

يمكن أن يكون وقت التشغيل معقدًا إلى حد ما إذا لم تكن تقوم فقط بترجمة جميع الرسائل الممكنة قبل تشغيل تطبيق Angular. إذا كنت تفعل ذلك ، فمن الممكن أن يكون النهج الجديد لترجمة ترجمة الوقت هو ما تحتاجه.

في i18n الجديد ، تحدث الترجمة في نهاية خط أنابيب البناء - وليس في مترجم Angular - وهذا يعني أنه يجب أن تكون قادرًا على تقديم رسائل غير مترجمة في المكتبات وما إلى ذلك ، ولا تقوم بالترجمة إلا عند إنشاء التطبيق النهائي.

هذا كل ما في أعمال الإصدار v9.0.0.

تحقق من https://github.com/angular/angular/tree/master/packages/localize لترى أين نحن.

petebacondarwin هل تمانع في التوسع قليلاً في ترجمة وقت التجميع الجديد؟ هل سيسمح لنا ذلك ببناء حزمة واحدة (مع AOT) تعمل لجميع اللغات؟

في النهج الجديد ، بدلاً من القيام بالترجمة داخل المترجم Angular ، نقوم ببساطة "بوضع علامة" على الرسائل التي تحتاج إلى أن تتم ترجمتها عبر معالج علامة سلسلة نصية عالمية $localize . تصمد هذه السلاسل المميزة بكل أنواع التجميع والتصغير ، بحيث تظل موجودة وقابلة للاكتشاف في نهاية خط أنابيب البناء. قد تكون هذه الملفات هي حزمة مكتبتك التي ترسلها إلى فريق آخر لتضمينها في تطبيقهم!

لدينا الآن خياران:

أ) قم بتشغيل أداة تحدد هذه الرسائل المميزة بشكل ثابت واستبدالها بالترجمات. يؤدي هذا بشكل فعال إلى إزالة المراجع $localize من JavaScript ويترك لك الحد الأدنى من حزمة التعليمات البرمجية للتوزيع. يمكن أن تأخذ أداة "تضمين وقت التجميع" عددًا من الترجمات وإنشاء نسخة من الحزمة الخاصة بك لكل لغة تقوم بترجمتها. نظرًا لأنه يمكن تشغيله في نهاية خط أنابيب البناء ، فإنه يتجنب الاضطرار إلى تشغيل جوانب أخرى من جهازك لكل لغة تدعمها.

ب) اسمح للعلامات $localize أن ينتهي بها الأمر في الكود الذي يتم تشغيله في المتصفح ، واستخدم تنفيذ $localize لترجمة الرسائل في وقت التشغيل. يتمثل الجانب السلبي لهذا الأسلوب في أن الحمولة إلى المتصفح أكبر نظرًا لأنه يجب أن يحتوي على مكالمات $localize ولكن أيضًا تطبيق الترجمة $localize . كما يجب عليك إرسال الترجمات نفسها إلى المتصفح. قد تكون إحدى فوائد هذا الأسلوب دعم التحميل البطيء للترجمات في وقت التشغيل. ولكن يمكن القول إن إجراء الترجمة على خادم http (أو خادم الإنشاء) يجعل تجربة وقت التشغيل أكثر كفاءة.

خيار وقت التشغيل ب) من فضلك. يمكننا تحميل الترجمات كملفات JSON وتبديل اللغات في وقت التشغيل كما نفعل حاليًا باستخدام ngx-translate .

شكرا على الشرح. أتفهم أن الطريقة أ) أكثر "زاوية" ولكن الميزة الكبيرة للنهج ب) (والتحميل البطيء بشكل عام) هي أيضًا القدرة على تحديد / تغيير الترجمات من قبل المستخدمين ديناميكيًا (يمكن استخدام الترجمات المعدلة للتطبيقات على الفور) . إذا فهمتها بشكل صحيح ، فإن أي تغيير بسيط في الترجمة في النهج أ) يعني إعادة بناء جديدة.

هذه هي نفس ميزة التبديل من الصفحات التي تم إنشاؤها بشكل ثابت مع مكونات Angular المحددة مسبقًا إلى القوالب التي ينشئها المستخدم والتي تحتوي على المكونات الزاوية التي يحددها المبرمج حسب رغبة المستخدم (سيتم أيضًا تحميل القالب المحدد بهذه الطريقة من قاعدة البيانات ... )

ربما تكون قد فكرت أيضًا في إمكانية استخدام النهج أ) افتراضيًا عند التحميل. إذا ظهر طلب ترجمة وقت التشغيل (على سبيل المثال ، ستبدأ الواجهة الخلفية في إرسال ترجمات أحدث) ، فسيبدأ الزحف إلى الكتل المحددة (التي تحتوي على نص ثابت حتى الآن) واستبدالها ديناميكيًا ، كما في الطريقة ب). لذلك ب) لن يتم تنشيطه إلا إذا لزم الأمر وسيتم إعداد جميع الأجزاء القابلة للترجمة وفقًا للإجراء أ). أفهم أن مثل هذا النهج سيكون أكثر إرهاقًا من ب) النهج نفسه وبالتأكيد ليس ممكنًا بشكل مباشر بهذه الطريقة ، ولكن هذا سيكون أقرب إلى الاحتياجات الفعلية للمستخدمين.

بالنسبة إلى الخيارات التي ذكرتها ، فأنا على استعداد للتضحية بحوالي 25٪ من أداء التطبيق في حالات معينة لتحقيق هذه الوظيفة الديناميكية (بالطبع لن أستخدم هذا النهج الديناميكي في كل مكان). لذلك إذا تم تقديم نموذج AOT المترجم في 0.4 ثانية ، في حالة إنشاء قالب ديناميكي في 0.5 ثانية ، سأظل أعتبره مقبولاً في التطبيقات التي أحتاج فيها إلى مثل هذه الردود الفورية لتغيير الترجمة.

سيكون كلا الأسلوبينdemisx متاحين مع الإصدار 9 ، ولكن الخيار أ فقط سيتم دعمه بالكامل في البداية (للتوافق الرجعي) ، وقد يتم تطوير أشياء جديدة للخيار ب) قبل اعتماده بالكامل من قبل فريق Angular.
مكتبتي Locl ستوفر بعض المساعدين للخيار ب) عند إصدار الإصدار 9 بحيث يمكن لأي شخص استخدامه ، حتى يقوم فريق Angular بسد هذه الفجوة

اعلم أن ترجمة وقت التشغيل هذه لن تكون "تفاعلية" بمعنى أنه بمجرد تقديم أحد المكونات لن يكون من الممكن تغيير نصه ديناميكيًا ، حتى إذا تم تحميل ترجمة جديدة.

تكون الرسائل المترجمة ثابتة بالنسبة إلى السلاسل ذات العلامات $localize . لذلك سيحتاج المكون إلى إعادة تصيير. واعتمادًا على التخزين المؤقت للقوالب في IVY ، قد لا تكون إعادة العرض كافية.

هذا هو أحد الأسباب التي تجعل ترجمة وقت التشغيل صعبة التنفيذ نظرًا لأن سلوكها لن يكون بالضرورة بديهيًا.

فيما يتعلق بالنهج المختلط المتمثل في البدء بترجمة ثابتة في الإنشاء ثم إضافة ترجمة وقت التشغيل لاحقًا. يمكن أن يكون هذا ممكنًا إذا لم يزيل تضمين وقت التجميع علامات $localize ولكن تم تحديث الأجزاء الحرفية للسلسلة النموذجية فقط. على الرغم من ذلك ، سيؤدي ذلك إلى تكلفة وقت الترجمة بالإضافة إلى تكلفة حجم الحزمة الإضافية.

يؤدي تشغيل ng xi18n على Angular 9 RC1 إلى إرجاع "نحن آسفون ولكن لم يتم تنفيذ i18n بعد في Ivy" ، لكن سجل التغيير يشير إلى وجود دعم _some_ i18n مطبق الآن. أفترض أن ملفات الترجمة بحاجة إلى التحديث يدويًا في الوقت الحالي؟

@ neil-119 الاستخراج حاليًا غير مدعوم في وضع اللبلاب. ما زلت بحاجة إلى تعطيل لبلاب لتشغيل الاستخراج. ولكن بعد ذلك يمكنك إعادة تمكينه لاستهلاك ملفات الترجمة المستخرجة.

آمل أن يتم التخطيط لتضمين الاستخراج في الإصدار الأخير من v9.

@ neil-119 يجب أن يستخدم Angular CLI تلقائيًا VE للاستخراج. لا يجب عليك فعل أي شيء حتى ينجح ذلك. نحن أيضًا نختبر ذلك ، لذا فأنا مندهش من كسره. هل يمكنك فتح قضية مع repro من فضلك؟

الاستخراج غير مدعوم حاليًا في وضع اللبلاب.

أو لا ، إنها سدادة عرض. حاليًا ، لدينا عملية آلية باستخدام استخراج السلاسل. كيف يمكننا الهجرة إلى Ivy إذا لم نتمكن من استخراج الترجمات تلقائيًا؟
التلاعب في sconfig.json every time ؟ هذا لا يبدو جيدًا بالنسبة لي.

fetis - لم أكن غير صحيح. إذا كنت تستخدم CLI ، فإن استدعاء ng xi18n سيعمل كما هو متوقع ، حتى عند تمكين Ivy.

تضمين التغريدة سأقوم بتجربة Ivy في مشاريعنا الحالية ، لذا آمل أن أؤكد ذلك قريبًا

مرحبًا ، لقد حاولت استخدامه في المكون الخاص بي (الزاوي 9.0.0-rc.1)

$localize `some string to localize`;

تم العثور عليها كمستند في الرمز المصدر لـ @ angular / localize / init.

عندما أحاول البناء كالمعتاد للغتي ، أحصل على هذا الخطأ
No translation found for "4145296873012977836" ("some string to localize").

كيف يمكنني تقديم ترجمة لتلك السلسلة؟
ما أتوقعه هو أن ng xi18n سينشئ ملف xlf مع هذا النص أيضًا من كود المكون. هل هذا صحيح أم أنني أفتقد شيئًا؟

مرحبًا @ Ks89 - استخراج الرسائل من كود التطبيق (بدلاً من القوالب) غير مدعوم للإصدار 9.
ولكن يمكنك حل ذلك إذا كنت متسترًا. 4145296873012977836 هو معرف الرسالة ، لذا إذا قدمت ترجمة في ملف الترجمة الخاص بك بهذا المعرف ، فسيتم استخدامها عند الترجمة.

petebacondarwin متى ستتم إضافة هذه الميزة إلى Angular؟
أعتقد أنه من المهم حقًا جعل ترجمات وقت التشغيل في المكون مفيدة حقًا.

عندما أرسل ملف xlf الخاص بي إلى مترجم ، أتوقع إضافة جميع السلاسل بسرعة ثم تطبيق النتيجة على التطبيق بسهولة بالغة.

شكرا على الاجابة

أتوقعه في 9.1

إذا كانت لدينا طريقة لفرض إعادة عرض التطبيق بالكامل بغض النظر عن ChangeDetectionStrategy لكل مكون ، فمن السهل جدًا حل هذه المشكلات الديناميكية.

تم إصدارpetebacondarwin Angular 9 الآن بوظيفة علامة localize $ الجديدة ، ولكن بدون استخراج الرسائل. لقد قلت من قبل أنه يمكننا توقع ذلك في Angular 9.1. هل ما زالت هذه التوقعات صالحة ، وهل يمكننا أن نتوقع استقرار واجهة برمجة تطبيقات $ localize؟

يمكنك استخراج الترجمات من القوالب.
إذا كنت تريد استخدام $localize في شفرتك أيضًا ، فيجب عليك إلقاء نظرة على Locl: https://github.com/loclapp/locl/
سيتيح لك @locl/cli الاستخراج من التعليمات البرمجية والقوالب

vekunz - التوقعات لا تزال سارية. علاوة على ذلك ، كما يشير ocombe ، تعمل آلية استخراج ترجمة CLI الحالية بشكل جيد لأي ترجمة موجودة داخل قالب Angular (أي الأشياء التي تم تمييزها بعلامات i18n ). الشيء الوحيد الذي لا يمكنك استخراجه باستخدام الأدوات الأساسية في الوقت الحالي هو المكالمات إلى $localize داخل الكود الخاص بك (على سبيل المثال في خدمة أو مكون).

استدعاء $localize بحد ذاته هو واجهة برمجة تطبيقات مستقرة.

الأدوات التي تقوم بالترجمة والاستخراج (تحديدًا في وقت الترجمة) لا تزال غير عامة. لكن هذا ليس مصدر قلق إلا إذا كنت تخطط لبناء الأدوات الخاصة بك حولها (مثل ocombe تفعل في Locl!).

شكرًا لك petebacondarwin ، باستخدام هذا ، يمكننا نسخ النصوص من التعليمات البرمجية إلى قالب مكون "مخفي" للاستخراج. ثم يجب أن يعمل كل من الاستخراج والترجمة ، أليس كذلك؟

ocombe مع توقع أن الاستخراج يعمل مع Angular 9.1 ، لن يدفع مديرنا مقابل الحل الخاص بك. خاصة لأننا لسنا بحاجة إلى التبديل المباشر للغات والمسارات المترجمة.

يمكننا نسخ النصوص من التعليمات البرمجية إلى قالب مكون "مخفي" لاستخراجها

نعم بالفعل ، سيعمل هذا الحل البديل في الوقت الحالي.

أنا في حيرة من أمري: هل ستكون ترجمة وقت التشغيل ممكنة أيضًا في 9.1؟ أو مجرد استخراج من خارج القوالب؟ أو لا شيء من هؤلاء؟

بالنسبة لي ، ستكون الترجمات في وقت التشغيل ميزة قاتلة. إن نشر حزم متعددة وإجبار المستخدم على إعادة تحميل الصفحة بأكملها ليس قابلية استخدام جيدة على ما أعتقد.

تضمين التغريدة
لقد قمت بإنشاء عرض توضيحي بسيط ، والذي يوضح ترجمة وقت التشغيل.
https://stackblitz.com/edit/ivy-vjqzd9؟file=src٪2Fapp٪2Fapp.component.ts

أهلا! أحاول الاتصال بـ loadTranslations في main.ts لأنه يتم ترجمة السلاسل أثناء استيراد تحليلات JavaScript ، لكن هذا لا يكفي.

يستورد main.ts AppModule الذي يستورد AppComponent (حيث أستخدم $localize ).

لإنجاحه ، أفعله:

loadTranslations(......);
import('./app/app.module').then(m => platformBrowserDynamic(). bootstrapModule(m.AppModule);

يعمل هذا الآن ولكنه يتسبب في تضمين حزمة Angular "complier.js" في حزمة البائع.

أي طريقة لتجنب ذلك؟ شكرا

حاليًا ، يجب استدعاء loadTranslations قبل بدء التطبيق ، لذا يمكن إجراؤه في polyfills.ts . وإذا كنت تريد تحميل مجموعة أخرى من الترجمات ، فعليك إعادة تحميل الصفحة. إذا كنت تريد أن تفهم أكثر قليلاً السبب ، فقد كتبت https://blog.ninja-squad.com/2019/12/10/angular-localize/ لشرح ذلك.

حاليًا ، يجب استدعاء loadTranslations قبل بدء التطبيق ، لذا يمكن إجراؤه في polyfills.ts .

إنه أسوأ من ذلك ، يجب استدعاؤه قبل استيراد أي ملف وحدة نمطية ، وهذا هو سبب نجاحه إذا قمت بوضعه في polyfills.ts (والذي يتم تنفيذه قبل ملف التطبيق الرئيسي) ، ولكن إذا كنت تريد استخدامه في ملفك "main" ثم تحتاج إلى استخدام import(...) ديناميكي للوحدة

vekunz ، إنه سبب وجيه لعدم استخدام lib الخاص بي في الوقت الحالي يقال إن Locl لا يتعلق فقط بالاستخراج ، أعتزم إضافة الكثير من الأدوات الأخرى لتبسيط i18n

هل هناك نية لتطبيق وقت التشغيل i18n في Angular على الإطلاق؟ كنا نتوقع الميزة منذ ما يقرب من ثلاث سنوات والآن Ivy هنا وما زالت نصف مخبوزة فقط.

هل هناك نية لتطبيق وقت التشغيل i18n في Angular على الإطلاق؟ كنا نتوقع الميزة منذ ما يقرب من ثلاث سنوات والآن Ivy هنا وما زالت نصف مخبوزة فقط.

ما أفهمه هو أن Ivy ، من نواح كثيرة ، عامل تمكين للأشياء القادمة. ليس من المستغرب أن تتحرك إبرة i18n بشكل لا يصدق مع إطلاق Ivy ، لكن يجب أن تطلق العنان لإمكانية حدوث تغييرات كبيرة في المستقبل. كانت هذه قراءتي لها ، وآمل على أي حال.

Karasuni - أعتقد أننا بحاجة إلى توضيح ما تعنيه ترجمة وقت التشغيل في الواقع للإطار الزاوي الأساسي نظرًا لوجود قدر كبير من الالتباس حوله.

التغييرات التي أجريناها على الإصدار 9 تتضمن الترجمة المستندة إلى $localize . كان الهدف الأساسي من ذلك هو فصل الترجمة عن المترجم Angular ، بحيث يتيح عددًا من التحسينات الرائعة:

أولها ، المتاح على الفور لجميع مستخدمي الإصدار 9 ، هو تسريع إنشاء التطبيقات المترجمة. في السابق ، كان لابد من تشغيل مسار الإنشاء بالكامل لكل لغة تريد ترجمة تطبيقك إليها. الآن يجب تشغيل التجميع الرئيسي للتطبيق الخاص بك مرة واحدة فقط ويتم تشغيل عملية الترجمة النهائية ، والتي تكون أقصر بشكل ملحوظ لكل لغة في إخراج الإصدار. لدعم ذلك ، توجد الحزمة الجديدة @angular/localize ، والتغييرات داخل مترجم Angular وحمل كامل من العمل داخل Angular CLI لجعل هذا سلسًا وشفافًا قدر الإمكان

ثانيًا ، نظرًا لأنه يمكن ترك العلامات $localize في الكود الموزع ، فمن الممكن الآن أيضًا إجراء الترجمة في المتصفح (في وقت التشغيل ، بدلاً من وقت الترجمة). هذا ما نعنيه في إطار العمل الزاوي الأساسي كترجمة وقت التشغيل. لكن من فضلك لا أن النتيجة النهائية لهذا هي بشكل فعال نفس الترجمة في وقت الترجمة. الترجمة تحدث مرة واحدة فقط ؛ إذا كنت تريد تغيير اللغة في وقت التشغيل ، فيجب عليك إعادة تشغيل التطبيق بالكامل (على سبيل المثال ، عبر إعادة التحميل). هذا له ميزة السماح للمشروع بنشر واحد قابل للتوزيع مع العديد من ملفات الترجمة ، وهو أمر مفيد في عدد صغير من حالات الاستخدام حيث لا ترغب في إنشاء جميع الترجمات المختلفة مقدمًا. هناك بعض المشكلات الصعبة حول تحميل الترجمات في وقت مبكر بما فيه الكفاية كما أشار ocombe وآخرون هنا. يمكنك التفكير في https://www.locl.app/ للحصول على مزيد من المساعدة للقيام بذلك.

لاحظ أنه يمكن أيضًا استخدام ترجمة "وقت التشغيل" هذه على مسارات محملة بطيئة ، لذا قد يكون من الممكن أن يكون لديك طرق مختلفة بلغات مختلفة اعتمادًا على كيفية إعدادك للأشياء.

نظرًا لعدم وجود طريقة واحدة لتحميل الترجمات تعمل مع جميع السيناريوهات ، لم نقم بتخزينها في CLI أو قدمنا ​​واجهات برمجة تطبيقات عامة مستقرة لدعم ذلك حتى الآن. بمجرد أن نفهم حالات الاستخدام بشكل أفضل ، فقد نتمكن من إضافة المزيد من الدعم لذلك. في هذه الأثناء ، قد تساعد أشياء مثل Locl إذا كنت لا ترغب في المغامرة في حلها بنفسك.

أخيرًا ، لاحظ أن التغيير الديناميكي للسلاسل المترجمة في وقت التشغيل غير مدعوم (حسب التصميم) من قبل إطار العمل Angular الأساسي. سيؤدي ربط السلاسل المترجمة إلى نظام Angular لاكتشاف التغيير إلى وضع الكثير من الضغط على معظم التطبيقات وإفساد الأداء. من خلال تفاعلاتي مع المجتمع ، لم أرَ تقريبًا أي سيناريوهات في العالم الحقيقي حيث يكون هذا مطلوبًا بالفعل بالإضافة إلى إعادة تشغيل التطبيق عند تغيير اللغة. إذا كان هذا مطلبًا لتطبيقك ، فيمكنك تحقيقه باستخدام أنبوب مخصص على السلاسل الخاصة بك في قوالب تسحب الترجمات ، وربما حتى استدعاء $localize سريعًا للترجمة ولكنه لا يبدو مثل سيكون هذا أداء للغاية. وإلا يمكنك التفكير في نهج أكثر ديناميكية مثل https://netbasal.gitbook.io/transloco/.

ستتمثل التغييرات الرئيسية القادمة في الإصدار الثانوي التالي من Angular في تحسين استخراج الترجمة ، والذي سيكون قادرًا على تحديد واستخراج السلاسل المترجمة من رمز TS - حاليًا ، يتعامل استخراج CLI مع السلاسل المترجمة في القوالب فقط.

لن تظهر التغييرات لتحسين ترجمة وقت التشغيل ، كما هو موضح أعلاه ، إلا بعد 9.1 على أقرب تقدير.

أخيرًا ، لاحظ أن التغيير الديناميكي للسلاسل المترجمة في وقت التشغيل غير مدعوم (حسب التصميم) من قبل إطار العمل Angular الأساسي. سيؤدي ربط السلاسل المترجمة إلى نظام Angular لاكتشاف التغيير إلى وضع الكثير من الضغط على معظم التطبيقات وإفساد الأداء. من خلال تفاعلاتي مع المجتمع ، لم أرَ تقريبًا أي سيناريوهات في العالم الحقيقي حيث يكون هذا مطلوبًا بالفعل بالإضافة إلى إعادة تشغيل التطبيق عند تغيير اللغة.

قد أكون مخطئًا ولكن في هذا الموضوع وحده أظهر العديد من الأشخاص اهتمامًا صريحًا بالقدرة على تغيير اللغة مباشرة ، في وقت التشغيل ، دون الحاجة إلى إعادة إنشاء التطبيق أو إعادة تحميله. أو هل لكل شخص هنا تعريف مختلف لـ runtime translation ؟

لا أريد إعادة تحميل تطبيق لمجرد تبديل اللغة. على سبيل المثال ، عندما يكون المستخدم في صفحة بها نموذج ، فإن إعادة تحميل صفحة كاملة للتبديل في الترجمة سيكون أمرًا مزعجًا للمستخدم.

فقط لأكون واضحا. ما قصدت قوله هو أن الكثير من الناس قد جاءوا لي ليقولوا إنهم بحاجة ماسة إلى تغيير اللغة الحية في طلباتهم. ولكن عندما تبحث في الأسباب يتبين أنها لا تفعل ذلك. أنا لا أقول أنه لا توجد سيناريوهات تتطلب ذلك ، لكن من خلال تجربتي خلال العام الماضي ، صادفت القليل جدًا.

سؤال: لماذا يحتاج المستخدم إلى تبديل اللغات عند الانتقال إلى نموذج معين في تطبيقك؟

لا أعتقد أن التبديل المباشر ضروري أيضًا. كم مرة تقوم بتغيير لغة موقع الويب؟ عادة مرة واحدة كحد أقصى. ولهذه المرة ، لا تعد إعادة تحميل الصفحة بهذه الأهمية. كما قال petebacondarwin ، فإن معظم السيناريوهات الخاصة بالتبديل المباشر ليست سيناريوهات ذات صلة في العالم الحقيقي ولكنها فقط "من الجيد امتلاكها".

أو هل لدى كل شخص هنا تعريف مختلف لترجمة وقت التشغيل؟

أنا بالتأكيد بحاجة إلى ترجمات وقت التشغيل. يحتاج عملاؤنا إلى أن يكونوا قادرين على تحرير وتحديث الترجمات في الميدان ، وليس فقط على خادم الإنشاء. لذلك ، وقت التشغيل ، بدلاً من وقت التجميع.

يعد التبديل الفعلي للغات بعد تحميل الصفحة أمرًا رائعًا.

فقط لأكون واضحا. ما قصدت قوله هو أن الكثير من الناس قد جاءوا لي ليقولوا إنهم بحاجة ماسة إلى تغيير اللغة الحية في طلباتهم. ولكن عندما تبحث في الأسباب يتبين أنها لا تفعل ذلك. أنا لا أقول أنه لا توجد سيناريوهات تتطلب ذلك ، لكن من خلال تجربتي خلال العام الماضي ، صادفت القليل جدًا.

سؤال: لماذا يحتاج المستخدم إلى تبديل اللغات عند الانتقال إلى نموذج معين في تطبيقك؟

قد تكون محقًا في أنه ليس مطلبًا قويًا. قد أحاول نشر الترجمات عند التحميل ولكنها ستحول تجربة المستخدم للتطبيقات القادرة حاليًا على تبديل اللغة ديناميكيًا - دون إعادة تحميل أو تغيير موضع في الصفحة - بمكتبة خارجية. كانت الترجمات موضوعًا ساخنًا لفترة طويلة جدًا.

لدي سؤال مهم: هل يمكن تحميل ملفات الترجمة بشكل غير متزامن؟ يتم تخزين جميع ترجماتي في قاعدة بيانات لأن القدرة على تحديثها دون إعادة بناء أمر مهم.

نعم ، يمكن تحميلها بشكل غير متزامن ، لكنك تحتاج إلى تأخير بدء التطبيق الخاص بك حتى يتم تحميلها

فقط لأكون واضحا. ما قصدت قوله هو أن الكثير من الناس قد جاءوا لي ليقولوا إنهم بحاجة ماسة إلى تغيير اللغة الحية في طلباتهم. ولكن عندما تبحث في الأسباب يتبين أنها لا تفعل ذلك. أنا لا أقول أنه لا توجد سيناريوهات تتطلب ذلك ، لكن من خلال تجربتي خلال العام الماضي ، صادفت القليل جدًا.
سؤال: لماذا يحتاج المستخدم إلى تبديل اللغات عند الانتقال إلى نموذج معين في تطبيقك؟

قد تكون محقًا في أنه ليس مطلبًا قويًا. قد أحاول نشر الترجمات عند التحميل ولكنها ستحول تجربة المستخدم للتطبيقات القادرة حاليًا على تبديل اللغة ديناميكيًا - دون إعادة تحميل أو تغيير موضع في الصفحة - بمكتبة خارجية. كانت الترجمات موضوعًا ساخنًا لفترة طويلة جدًا.

من الناحية الفنية ، يمكنك إعادة تحميل التطبيق بالكامل مع إبقاء المستخدم في مكانه.
أنت بحاجة "فقط" إلى تطبيق تحكمه الحالة (مع ngxs أو ngrx أو أي مكتبة إدارة حالة أخرى) يتم تخزينها في مكان ما واستردادها عند بدء التشغيل.

ستكون الحيلة الوحيدة هي الاحتفاظ بموضع التمرير ولكن هذا ممكن أيضًا.

petebacondarwin علي أن أقول إنني أتفق معك. لا أعرف المستخدمين النهائيين الحقيقيين (باستثناء المختبرين في مرحلة التطوير) الذين يبدلون تطبيقًا بشكل دائم بين اللغات عند استخدامه. بالتأكيد ، ربما يفعلون ذلك في البداية إذا قاموا بفتحه بطريقة مختلفة بطريقة ما ، ولكن لاحقًا ، إنها حالة نادرة.

أو هل لدى كل شخص هنا تعريف مختلف لترجمة وقت التشغيل؟

أنا بالتأكيد بحاجة إلى ترجمات وقت التشغيل. يحتاج عملاؤنا إلى أن يكونوا قادرين على تحرير وتحديث الترجمات في الميدان ، وليس فقط على خادم الإنشاء. لذلك ، وقت التشغيل ، بدلاً من وقت التجميع.

يعد التبديل الفعلي للغات بعد تحميل الصفحة أمرًا رائعًا.

لست متأكدًا مما يفعله عملاؤك ، ولكن "تحرير الترجمات مباشرة في موقع الإنتاج" لا يبدو وكأنه سيناريو شائع.

لا أرى تغيير اللغة على الهواء مباشرة (_ بدون إعادة تحميل الصفحة_) لتكون بمثابة عائق للصفقة.
يحدث تغيير لغة للمستخدم مرة واحدة فقط ؛

فكر في الأمر ، كم مرة قمت بتغيير لغة هاتفك؟ ربما مرة واحدة أو أنك بدأت للتو باستخدام اللغة الافتراضية.

إن مشاهدة التغييرات اللغوية من أجل إجراء تغيير مباشر دون إعادة تحميل الصفحة يجلب الكثير من الأداء الجزئي لشيء بالكاد يُستخدم طوال عمر المستخدم.

في النهاية ، يصل الأمر إلى 3 أشياء بالنسبة لي ؛

1. استخراج الترجمات من القوالب وملفات TS.
   
   
   
   • تحديث مصدر lang الأصول.
   
   
   • تحديث الترجمة أيضًا (_ إذا كان لدي عدة لغات ، fr ، en ، de ... أريد تحديثها جميعًا بمفاتيح ترجمة جديدة ومفاتيح تمت إزالتها ._)
   
   
2. بناء واحد لجميع الترجمات (يعد وجود إصدار واحد لكل ترجمة جيدًا أيضًا ، طالما أنه لا يضاعف وقت الإنشاء ._)
3. الحصول على اللغات المتاحة وتغيير اللغة مع إعادة التحميل.

تضمين التغريدة
يمكنك جلب الترجمات غير متزامنة وبعد ذلك فقط تحميل التطبيق الزاوي.
انظر تعليقي أعلاه حول كيفية تحميل app.module غير متزامن باستخدام import(...) .

أنا شخصياً أستخدم ويكيبيديا لمعرفة عنوان الفيلم الذي أعلم أنه "تمت ترجمته" إلى لغة أخرى.

في هذا اليوم وهذا العصر ، يعد التحدث بلغتين أو ثلاث لغات أمرًا شائعًا (بصرف النظر عن داخل الولايات المتحدة ، لا يعني أي ضرر).

قد يرغب المستخدم في التبديل بين اللغات ، فهذا أمر معقول تمامًا. مثال ويكيبيديا هو نتيجة إيجابية لتمكين هذا ، لا أفهم لماذا يجب علينا خنق الاستخدامات المحتملة الأخرى قبل أن يعيشوا لرؤية ضوء النهار تحت ذريعة الأداء.

حتى ترجمة ngx الخاصة بـ ocombe والتي يجب أن تكون مثالاً مساويًا لك يا رفاق على "الترجمات ذات الأداء الضعيف" ، كانت تعمل بسرعة كافية بما يكفي للمستخدم العادي.

أنا شخصياً أتحدث ثلاث لغات ولا يمكنني الاستقرار على استخدام لغة واحدة: كل اللغات جميلة بالنسبة لي

مع كل ما قيل لا يمكنني الموافقة على هذا:

فكر في الأمر ، كم مرة قمت بتغيير لغة هاتفك؟ ربما مرة واحدة أو أنك بدأت للتو باستخدام اللغة الافتراضية.

ويكيبيديا هي أسوأ مثال على ذلك لأن اللغات المختلفة للمقالة هي في الواقع مقالات مستقلة. عادة لا تحتاج إلى لغات مختلفة لنفس الموقع بالضبط. حتى لو كنت تعمل رباعي اللغات.
وإذا كنت بحاجة فعلاً إلى التبديل المباشر ، فيمكنك استخدام الحل البديل مع أنبوب الترجمة المخصص ، والذي ذكره petebacondarwin أو الأداة الجديدة منocombe.

حسنًا ، لذلك لا أعتقد أن هذا هو أفضل مكان لإجراء هذه المناقشة حقًا. إنني قلق من أنه (على الرغم من أننا كنا جميعًا معقولاً للغاية حتى الآن) فقد ننزلق إلى مناقشة سلبية. أخشى أنه في المستقبل المنظور ، لن يوفر إطار العمل Angular حلاً مباشرًا لتبديل اللغة.

أشعر أن قيمة هذه القضية قد وصلت إلى مجراها. لقد قمت بنقل القضايا المفتوحة والعلاقات العامة المرتبطة في وصف هذه المشكلة إلى https://github.com/angular/angular/milestone/101 وسأغلق هذا PR وإغلاقه.

إذا كانت لديك إصدارات جديدة لطلبات الميزات ، فيرجى فتح مشكلة جديدة ووضع علامة علي فيها.