Moment: في ، في الولايات المتحدة المحلية

تم إنشاؤها على ٢٤ نوفمبر ٢٠١٦  ·  42تعليقات  ·  مصدر: moment/moment

فقط سؤال:

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

شكرا لعملك الرائع تبقي على دفع!

التعليق الأكثر فائدة

icambron My environment هو تطبيق React Native يستخدم npm للتحكم في تبعياتي ، وقد تمكنت من تكرار الفشل حتى في الحد الأدنى من تطبيقات العينة. تكمن المشكلة في أنه في دالة loadLocale ، تحاول طلب ('./ locale /' + name) حيث يكون الاسم en-US ، وهذا يتطلب فشلًا. عندما يتطلب ذلك فشلًا في إصدار الإصدار ، فإنه يتسبب في تعطل التطبيق مع تتبع المكدس على غرار ما يلي:

E/ReactNativeJS: Requiring unknown module "./locale/en-us".
E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
                                                                Process: com.myApp, PID: 30054
                                                                com.facebook.react.common.JavascriptException: Requiring unknown module "./locale/en-US"., stack:
                                                                o<strong i="7">@2</strong>:742
                                                                n<strong i="8">@2</strong>:426
                                                                i<strong i="9">@2</strong>:278
                                                                t<strong i="10">@2</strong>:210
                                                                Xe<strong i="11">@648</strong>:16702
                                                                nt<strong i="12">@648</strong>:17804
                                                                gt<strong i="13">@648</strong>:22583
                                                                yt<strong i="14">@648</strong>:22460
                                                                wt<strong i="15">@648</strong>:23200
                                                                c<strong i="16">@648</strong>:1112
                                                                parse<strong i="17">@645</strong>:1536
                                                                render<strong i="18">@643</strong>:2923
                                                                _renderValidatedComponentWithoutOwnerOrContext<strong i="19">@141</strong>:7295
                                                                _renderValidatedComponent<strong i="20">@141</strong>:7462
                                                                performInitialMount<strong i="21">@141</strong>:3012
                                                                mountComponent<strong i="22">@141</strong>:2056
                                                                mountComponent<strong i="23">@132</strong>:205
                                                                performInitialMount<strong i="24">@141</strong>:3162
                                                                mountComponent<strong i="25">@141</strong>:2056
                                                                mountComponent<strong i="26">@132</strong>:205
                                                                performInitialMount<strong i="27">@141</strong>:3162
                                                                mountComponent<strong i="28">@141</strong>:2056
                                                                mountComponent<strong i="29">@132</strong>:205

بالنظر إلى الكود ، نظرًا لأن getLocale يرى أن مفتاحي ("en-US") ليس مصفوفة ، فإنه يقع في loadLocale دون محاولة مطابقة "en" ، وهو ما سيحدث فقط إذا انتقلت إلى وظيفة ChooseLocale.

تحرير: بعد البحث عن كثب في وظيفة selectLocale ، ستظل تحاول أولاً اختيار "en-US" ثم تفشل في الطلب قبل محاولة "en" على الإطلاق ، وبالتالي فإن الطلب الفاشل الذي يؤدي إلى تعطل التطبيق سيظل يحدث حتى إذا كانت هذه مجموعة.
الغريب أيضًا هو حقيقة أن البقعة التي يتم كسرها داخل تجربة / التقاط ، ولكنها تسبب في حدوث عطل على أي حال. هذا في الواقع هو الشيء المحير حقًا هنا.

تحرير 2: لاحظ أن الطلب يفشل بأمان عندما يكون في تصحيح (__DEV__) بناء ومن ثم يتراجع لاستخدام "en". لست متأكدًا من سبب كون الطلب أكثر إثارة للانفجار في __PROD__ ، لكنه بالتأكيد ينكسر هنا في اللحظة.

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

ال 42 كومينتر

هناك لغة en ، فهي لا تأتي في ملف منفصل. يتم قبوله كثيرًا من خلال moment().locale() و moment.locale() :

moment.locale('fr')
"fr"
moment().format("LLLL")
"vendredi 25 novembre 2016 03:39"
moment.locale('en')
"en"
moment().format("LLLL")
"Friday, November 25, 2016 3:39 AM"

en-US يعمل أيضًا لأننا نسير في البحث عن تطابق أقل تحديدًا ولغة en هي الإنجليزية الأمريكية:

moment.locale('en-GB')
"en-gb"
moment().format("LLLL")
"Friday, 25 November 2016 03:40"
moment.locale('en-US')
"en"
moment().format("LLLL")
"Friday, November 25, 2016 3:40 AM"

أنا لا أشتريه ؛ ضع في اعتبارك الحالة التي يتم فيها اكتشاف اللغة من البيئة ، ومن ثم يتم إنشاء مسار مطلوب لتحميل اللحظة / اللغة / $ {discoveryLocale}. إذا كان هذا المتغير هو "en" أو "en-us" ، فسيفشل برنامج requestjs في تحميل ملف (يحصل على 404). إذا تم اكتشافه على أنه "de" ، فسيتم تحميل الملف.

يعرف مُحمل اللغة في eigood Moment أنه يحتوي بالفعل على اللغة الإنجليزية ولا يحاول تحميله من ملف خارجي.

icambron لا أعتقد أنك محق في السير في الشجرة عندما يمر المستخدم في "en-US" كموقع محلي. في الواقع ، أقوم حاليًا بتصحيح الأخطاء من خلاله وهي تتعطل لأنك لا تمشي على الشجرة.
حالة الاستخدام الخاصة بي هي أنني اتصلت بـ moment.utc (myDate ، myFormat ، locale ، true) حيث تكون اللغة المحلية عبارة عن سلسلة واحدة فقط "en-US". نظرًا لأنه لا يمكن استيراد هذه السلسلة (نظرًا لعدم وجود ملف لها) ولكنها ليست مصفوفة ، فإنها تحاول طلب اللغة ، ثم تقطع بيئات الإنتاج.
يبدو لي أن أفضل سلوك حقيقي هو تضمين en-US في قائمة المواقع الموجودة افتراضيًا (ليست موجودة الآن ، فقط en بمفردها).

steveccable حسنًا ، يحاول تحميله ، فقط في حال كان لديك ترجمة أكثر تحديدًا. عندما يفشل ، فإنه يحاول فقط "en" وينجح. أعتقد أن قطع الاتصال هو أن فشل تحميل "en-US" بطريقة ما ينكسر بالنسبة لك. لا شيء يفترض أن ينفجر هنا. من المفترض أن تفشل برشاقة وتنتقل إلى الخيار التالي. لذا عليك أن تخبرني المزيد عن بيئتك: ما الخطأ الذي يحدث على وجه التحديد؟

icambron My environment هو تطبيق React Native يستخدم npm للتحكم في تبعياتي ، وقد تمكنت من تكرار الفشل حتى في الحد الأدنى من تطبيقات العينة. تكمن المشكلة في أنه في دالة loadLocale ، تحاول طلب ('./ locale /' + name) حيث يكون الاسم en-US ، وهذا يتطلب فشلًا. عندما يتطلب ذلك فشلًا في إصدار الإصدار ، فإنه يتسبب في تعطل التطبيق مع تتبع المكدس على غرار ما يلي:

E/ReactNativeJS: Requiring unknown module "./locale/en-us".
E/AndroidRuntime: FATAL EXCEPTION: mqt_native_modules
                                                                Process: com.myApp, PID: 30054
                                                                com.facebook.react.common.JavascriptException: Requiring unknown module "./locale/en-US"., stack:
                                                                o<strong i="7">@2</strong>:742
                                                                n<strong i="8">@2</strong>:426
                                                                i<strong i="9">@2</strong>:278
                                                                t<strong i="10">@2</strong>:210
                                                                Xe<strong i="11">@648</strong>:16702
                                                                nt<strong i="12">@648</strong>:17804
                                                                gt<strong i="13">@648</strong>:22583
                                                                yt<strong i="14">@648</strong>:22460
                                                                wt<strong i="15">@648</strong>:23200
                                                                c<strong i="16">@648</strong>:1112
                                                                parse<strong i="17">@645</strong>:1536
                                                                render<strong i="18">@643</strong>:2923
                                                                _renderValidatedComponentWithoutOwnerOrContext<strong i="19">@141</strong>:7295
                                                                _renderValidatedComponent<strong i="20">@141</strong>:7462
                                                                performInitialMount<strong i="21">@141</strong>:3012
                                                                mountComponent<strong i="22">@141</strong>:2056
                                                                mountComponent<strong i="23">@132</strong>:205
                                                                performInitialMount<strong i="24">@141</strong>:3162
                                                                mountComponent<strong i="25">@141</strong>:2056
                                                                mountComponent<strong i="26">@132</strong>:205
                                                                performInitialMount<strong i="27">@141</strong>:3162
                                                                mountComponent<strong i="28">@141</strong>:2056
                                                                mountComponent<strong i="29">@132</strong>:205

بالنظر إلى الكود ، نظرًا لأن getLocale يرى أن مفتاحي ("en-US") ليس مصفوفة ، فإنه يقع في loadLocale دون محاولة مطابقة "en" ، وهو ما سيحدث فقط إذا انتقلت إلى وظيفة ChooseLocale.

تحرير: بعد البحث عن كثب في وظيفة selectLocale ، ستظل تحاول أولاً اختيار "en-US" ثم تفشل في الطلب قبل محاولة "en" على الإطلاق ، وبالتالي فإن الطلب الفاشل الذي يؤدي إلى تعطل التطبيق سيظل يحدث حتى إذا كانت هذه مجموعة.
الغريب أيضًا هو حقيقة أن البقعة التي يتم كسرها داخل تجربة / التقاط ، ولكنها تسبب في حدوث عطل على أي حال. هذا في الواقع هو الشيء المحير حقًا هنا.

تحرير 2: لاحظ أن الطلب يفشل بأمان عندما يكون في تصحيح (__DEV__) بناء ومن ثم يتراجع لاستخدام "en". لست متأكدًا من سبب كون الطلب أكثر إثارة للانفجار في __PROD__ ، لكنه بالتأكيد ينكسر هنا في اللحظة.

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

لذلك بعد العمل عليها قليلاً ، لدي حل بديل (أقل من مثالي). في الأساس ، كلما حاول الكود الخاص بي المرور في منطقة محلية من "en-US" ، أعترضه وأمرر في لغة "en" بدلاً من ذلك. يُسمح للمناطق الأخرى بالمرور دون تغيير.

بعد قولي هذا ، ما زلت أعتقد أنه من الصعب العثور على en-US أو عدم وجوده بشكل افتراضي ، ولا يمكنك تضمينه على وجه التحديد كما يمكنك مع المواقع الأخرى لتجنب الفشل في العثور عليه عندما يتم استدعاؤه بالفعل بناء على.

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

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

صحيح ، هذا ما أقوله. أحاول أن أفهم لماذا قد تكون المكالمة الفاشلة كارثية. لن أساعد في الترميز الثابت بمعرفة en-US ؛ لا يزال لدينا فشل مماثل في أي حالة احتياطية أخرى. على سبيل المثال ، هذا لا علاقة له بكون en حالة خاصة ، بل يتعلق بالعملية الاحتياطية التي لا تعمل على الإطلاق في بيئتك.

من خلال العمل من خلاله ، يبدو أن React Native لا تتعامل مع المتطلبات الفاشلة بأمان كما نحب. أنت محق في أنه لا علاقة له بكونك حالة خاصة ، والسبب الوحيد الذي بدا وكأنه حالة خاصة هو عدم وجود طريقة لمنع طلب en-US من الفشل (نظرًا لأنه لا يمكننا استيراده مباشرة كما هو الحال مع المواقع الأخرى). كما ذكر في التعديل الأخير ، لا تعمل المحاولة / catch لأنها تفشل بشكل غير متزامن.
في الوقت الحالي ، الحل البديل الذي ذكرته أعلاه لمجرد تعقيم مواقع "en-US" يعمل من أجل أغراضي.

لا تعمل المحاولة / catch لأنها تفشل بشكل غير متزامن

أوه ، فاتني هذا التعديل. كان ذلك سيكون تخميني أيضا

تضمين التغريدة
لست متأكدًا مما إذا كنت لا تزال تواجه المشكلة ، ولكن نفس الأعطال بالضبط في إصدار الإصدار (على الرغم من اللغة الفرنسية) استهلكت يومًا من العمل بالنسبة لي 😢

E/ReactNativeJS: Requiring unknown module "./locale/fr".
(...)

لقد قمت بحلها بـ:

import 'moment/locale/fr';

ربما يساعد

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

حصلت على مشاكل بعد الإصدار 2.19.2 ، وهنا ما تغير مع هذا الإصدار https://github.com/moment/moment/compare/29afed6...328d51e بدأت وظيفة updateLocale باستخدام loadLocale داخليًا والذي بدوره يتطلب الاستخدام بسلسلة ديناميكية https : //github.com/moment/moment/blob/fea48bb69eda8c0459915d6aa66a910a4d43a55b/moment.js#L1845

أعتقد أن هذا فشل في التفاعل الأصلي لأنه لا يمكنك طلب الملفات ديناميكيًا عن طريق متغير https://github.com/facebook/react-native/issues/6391

في حالتي المحددة ، أقوم باستيراد ملف en-gb ، لذا يجب العثور عليه في locales[name] بحلول الوقت الذي أتصل به moment.locale. لست متأكدًا من سبب فشل الطلب.

لست متأكدًا من أن RN يمثل أولوية أم لا ، ولكن سيتم كسر لحظة RN لعدة أشهر.

مع كل هذا ، يبدو أن facebook # 69 هو الحل الأكثر إنتاجية لإلغاء حظر الجميع. سأتحدث إلى jeanlauliac وسنرى ما إذا كان بإمكاننا دمجها يوم الاثنين.

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

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

بالنسبة لـ RN ، عملت في وضع الإصدار عن طريق التجريد إلى الجزء الأول من اللغة (ربما ما تفعله اللحظة خلف الشاشات عندما تفشل في تحميل لغة "xx-XX"). في المقتطف التالي ، locale هي لغة جهازك في الشكل "xx-XX".

moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-')))

هذا سلوك غريب.

https://stackoverflow.com/a/47260841/175825 تحتاج إلى استيراد إعدادات محلية معينة للنظام البيئي حتى تتمكن من استهلاكها.

بسبب هذا السحر ، لا يمكنني الحصول على تقويم كبير للتفاعل لعرض التواريخ مثل mm/yy باستخدام BigCalendar.momentLocalizer() لأنه يتوقع تحميل أي لغة.

يمكنني فتح مشكلة مع التقويم الكبير ، لكن ماذا عن lib التالي الذي صادفته والذي يتوقع لغة معينة؟ وماذا بعد؟

فقط أضف لغة en-us وافتراضي للسحر.

فقط أضف لغة en-us وافتراضي إلى السحر.

لن تحل المشكلة ، فهناك لغات مثل الإسبانية ( es-ES => es ) تقوم بعمل احتياطي تلقائي.

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

import moment from 'moment/min/moment-with-locales.min.js';

// locale is the locale detected by react-native-device-info
// ts is the time
export const formatTime = (locale, ts) => {
const m = moment.utc(ts);
locale = chooseMomentLocale(locale);
m.locale(locale);
// other logic to determine whether to show the time as "9:43 pm", "yesterday", or "7/8/2018"

return formattedTime;
}

/**
 * Checks if the device locale is available in moment and returns the locale to be loaded
 * <strong i="7">@param</strong>  {string} locale locale to be checked
 * <strong i="8">@return</strong> {string}        locale to be loaded by moment
 */
const chooseMomentLocale = (locale) => {
  // make the locale lower case 
  // will fix crashes caused by "en-GB" (instead of "en-gb") not being found
  locale = locale.toLowerCase();  
  if (moment.locales().includes(locale)) { // check if the locale is included in the array returned by `locales()` which (in this case) tells us which locales moment will support
    return locale;
  } else if (moment.locales().includes(locale.substring(0, 2))) { 
    // check if the first two letters of the locale are included in the array returned by `locales()` which (in this case) tells us which locales moment will support
    // will fixes crashes caused by "en-US" not being found, as we'll tell moment to load "en" instead
    return locale.substring(0, 2);
  }
    // use "en-gb" (the default language and locale for my app) as a fallback if we can't find any other locale
    return 'en-gb'; 
};

لقد واجهت أيضًا هذه المشكلة باستخدام React Native وتمكنت من تجنبها من خلال تضمين جميع اللغات إلى جانب Moment ، أي

import moment from 'moment'
import 'moment/min/locales'

(بدلاً من ذلك ، يتوفر أيضًا moment/min/moment-with-locales ولكنه لم يكن متوافقًا مع بعض التنسيقات الأخرى الخاصة بنا.)

هذه قضية مزعجة للغاية.

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

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

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

image

بالنسبة لـ RN ، عملت في وضع الإصدار عن طريق التجريد إلى الجزء الأول من اللغة (ربما ما تفعله اللحظة خلف الشاشات عندما تفشل في تحميل لغة "xx-XX"). في المقطع التالي ، locale هي لغة جهازك على شكل "xx-XX".

moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-')))

يعمل هذا الحل بالنسبة لي ، باستخدام i18n و momentjs مثل هذا:

// imports:
import moment from 'moment';
import i18n from './i18n';
import 'moment/locale/fr';

// constructor: 
moment.locale(i18n.locale.indexOf('-') === -1 ? i18n.locale : i18n.locale.substr(0, i18n.locale.indexOf('-')));

ما زلت أجرب هذه المشكلة أثناء تشغيل الإصدار "لحظة": "^ 2.22.2" ،
أي تصحيح في الإصدار الأخير؟

سوف تتناغم مع هذه القضية.

  1. يعتبر التعامل مع en-US على أنها مختلفة بشكل افتراضي مخفي والآخر تصميمًا سيئًا.
  2. بدون لغة en-us ، لا أعرف إصدار CDN الذي يجب استخدامه.
  3. تبدو Moment مثيرة للإعجاب ، ولكن لم أجد حلاً آخر لأن en-US ليست مثل المواقع الأخرى هي رائحة كود سيئة.

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

function parseLocaleForMoment (language) {
  if (language.indexOf('-') === -1) return language
  else return language.substr(0, language.indexOf('-'))
}

يبدو أن RN تمتص مع اللحظة لدرجة أنه من الأسهل فقط كتابة منسق أصلي. ربما سطر واحد فقط من التعليمات البرمجية ، مضاد للرصاص للعمل.

انتهى الأمر بإصلاحه مثل هذا:

const subLocales = [
  'ar-tn',
  'ar-dz',
  'ar-kw',
  'ar-ma',
  'ar-sa',
  'ar-ly',
  'de-at',
  'de-ch',
  'en-sg',
  'en-au',
  'en-ca',
  'en-gb',
  'en-ie',
  'en-nz',
  'es-us',
  'es-do',
  'fr-ca',
  'fr-ch',
  'gom-latn',
  'hy-am',
  'pa-in',
  'pt-br',
  'sr-cyrl',
  'tl-ph',
  'tlh',
  'tet',
  'ms-my',
  'it-ch',
  'tzl',
  'tzm',
  'tzm-latn',
  'nl-be',
  'ug-cn',
  'uz-latn',
  'zh-cn',
  'zh-hk',
  'zh-tw'
];

let momentLocale = i18n.locale.toLowerCase();

if (!subLocales.includes(momentLocale)) {
  momentLocale = momentLocale.substring(0, 2);
}

moment.locale(momentLocale);

من خلال رد فعل tapz الأصلي للأسف يبدو أن هذا يعمل على Android ولكن للأسف على نظام iOS: / أواجه بعض المشاكل مع لغة zh لبعض الأسباب: /

قد يكون ذلك بسبب تنسيق zh وبعض اللغات الأخرى بشكل مختلف للتمييز بين المبسطة والتقليدية. راجع https://gist.github.com/jacobbubu/1836273

@ rajivshah3 بالفعل كنت أواجه zh_Hant_HK والذي لم يكن يعمل مع طريقة tapz ، أنا الآن أستخدم طريقتك التي تبدو أفضل طريقة للتعامل مع هذه المشكلة بأكبر قدر ممكن من السلاسة ، شكرًا لمشاركتك 👍

نفس المشكلة ، في وضع الإنتاج RN فقط.

يبدو أن هذا يعمل بشكل جيد بالنسبة لي.

import 'moment/locale/fr';
import 'moment/locale/es';
import 'moment/locale/de';
import 'moment/locale/en-gb';
import 'moment/locale/es-us';

const toMomentLocale = locale => {
  let momentLocale = locale;
  momentLocale = momentLocale.replace('_', '-').toLowerCase();
  momentLocale = ['en-gb', 'en-us'].includes(locale)
    ? momentLocale
    : momentLocale.split('-')[0];
  return momentLocale;
};

طالما يتم استيراد البيانات (أو en ) وتراعي الحالة ، يبدو أنها تعمل بشكل جيد بالنسبة لنا

هذا سخيف حقا. إن إزالة قسم -region من كود اللغة ليس حلاً.

1) تفقد الخصوصية الإقليمية للغة.
2) والأسوأ من ذلك ، أن هذه الطريقة ستسبب المزيد من الأعطال. الصينية ( zh ) ، على سبيل المثال ، غير موجودة حتى في لغات MomentJS. تم تحديد zh-cn و zh-hk و zh-tw . لذلك إذا كنت تستخدم الكود أعلاه لاستبعاد المناطق من سلسلة الإعدادات المحلية ، فسوف يتعطل تطبيقك فورًا على معظم الأجهزة الصينية. مجرد تافه ~ 800 مليون مستخدم للهواتف الذكية.

الحل المؤقت الخاص بي لـ React Native هو:

const locale = 'zh-cn'; // or en-US etc
const languageCode = moment.locale(locale.indexOf("-") === -1 ? locale : locale.substr(0, locale.indexOf('-'))); // now 'zh', 'en' etc. Thanks <strong i="14">@adesmet</strong> 
let momentJsLocale;
switch(languageCode.toLowerCase()) {
  case 'zh':
    // No 'zh' locale exists in MomentJS. App will crash in production if used.
    momentJsLocale = 'zh-cn';
    break;
  case 'pa':
    momentJsLocale = 'pa-in';
    break;
  case 'hy':
    momentJsLocale = 'hy-am';
    break;
  default:
    momentJsLocale = languageCode.toLowerCase();
}
moment.locale(momentJsLocale);

adammcarth مرحبًا ، هل لدينا أي أخبار حول إصلاح اللغات اللحظية لـ RN؟

هذا تعطل للتو في إصدار إصدار الآن باستخدام en-gb .

لدي مشكلة مماثلة مثل ؛ تضمين التغريدة

عندما أضفت Luxon مع مشكلات منتقي الوقت ، ظهرت على السطح ويبدو أنها مرتبطة باللغة "en-US".

steveccable حسنًا ، يحاول تحميله ، فقط في حال كان لديك ترجمة أكثر تحديدًا. عندما يفشل ، فإنه يحاول فقط "en" وينجح. أعتقد أن قطع الاتصال هو أن فشل تحميل "en-US" بطريقة ما ينكسر بالنسبة لك. لا شيء يفترض أن ينفجر هنا. _ من المفترض أن تفشل برشاقة_ وتنتقل إلى الخيار التالي. لذا عليك أن تخبرني المزيد عن بيئتك: ما الخطأ الذي يحدث على وجه التحديد؟

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

يجب أن تكون هناك طريقة أفضل وأبسط خاصة بالنسبة لمكان كبير مثل "en-US".
في النهاية ، يجب فحص ومعالجة هذه المناطق التي بها إمكانية وجود جمهور / استخدام كبير في المقدمة ، للنظر في السرعة.

لقد قمت بتعديل الحل من slorber ليكون أكثر قوة. يؤدي هذا إلى إعادة تنسيق الإعدادات المحلية الواردة (على سبيل المثال "zh_CN" إلى "zh-cn") والتحقق مما إذا كانت مدعومة بالتثبيت اللحظي ، والعودة إلى البلد ، ثم الرجوع إلى en-us.

const toMomentLocale = (locale) => {
  let newLocale = locale.replace('_', '-').toLowerCase();
  let tryLocales = [newLocale, newLocale.split('-')[0]];
  for (let i = 0; i < tryLocales.length; i++) {
    if (moment.locales().indexOf(tryLocales[i]) >= 0) return tryLocales[i];
  }
  return 'en-us';
};

// use it like this:
let m = moment();
m.locale(toMomentLocale('zh_CN')).format('LLL'); // "2019年12月11日上午9点33分" -- used "zh-cn"
moment.locale(toMomentLocale('ja_JP'));
moment().format('LLL') // 2019年12月11日 09:34 -- falls back to "ja"

نفس المشكلة ، في وضع IOS إنتاج RN فقط.

يبدو أن هذا يعمل بشكل جيد بالنسبة لي.

لحظة استيراد من "لحظة" ؛
استيراد "لحظة / لغة / أماكن" ؛

قضيت بعض الوقت في تصحيح هذا الخطأ ، شكرًا لك jorodriguez على هذا

لا تزال هذه مشكلة 😢

اهلا ياجماعة،

لقد أنشأت حزمة صغيرة لك -> https://github.com/tonix-tuft/moment-utl

npm install --save moment moment-utl

يمكنك استخدام ما يلي لتحديد جميع لغات اللحظة المدعومة دون الحاجة إلى تحميلها مسبقًا:

import { allSupportedLocales, allSupportedLocalesMap } from "moment-utl";

const locales = allSupportedLocales(); // As an array: ["af", "ar", "ar-dz", "ar-kw", "ar-ly", "ar-ma", "ar-sa", "ar-tn", "az", "be", "bg", ...,  "en", ..., "zh-tw"]

const localesMap = allSupportedLocalesMap(); // As an object: { "af": 1, "ar": 2, "ar-dz": 3, "ar-kw": 4, "ar-ly": 5, "ar-ma": 6, "ar-sa": 7, "ar-tn": 8, "az": 9, "be": 10, ..., "en": 27, "zh-tw": 128 };

يعتمد moment-utl نظير على moment ، لكنه يجمع كل اللغات المحلية moment
أخذهم من الدليل moment/locale أثناء إنشاء حزمة تبعية dev moment .

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

يمكنك استخدامه مع الأمر npx :

npm install -g npx    # Install npx if you don't have it yet
npx moment-utl-locales    # Run this command from your project's root folder

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

آمل أن يساعد هذا!

ردًا على adammcarth ، يرجى التحقق من إجابتي هنا: https://github.com/tonix-tuft/moment-utl/issues/1#issuecomment -616088826

لقد طاردت هذه المشكلة الأشخاص في Odoo وكان الإصلاح المقترح هو إنشاء ملف en-us يدويًا. تنهد.

ما لا أفهمه هو سبب محاولة Mom تحميل ملف en-us إذا ، كما ورد في بعض التعليقات أعلاه ، يجب أن يعرف المُحمل أنه يحتوي بالفعل على "en" وليس استيراده ديناميكيًا.

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

وجود تقصير خفي هو مجموعة من المفاجآت ...

image

لقد طاردت هذه المشكلة الأشخاص في Odoo وكان الإصلاح المقترح هو إنشاء ملف en-us يدويًا. تنهد.

ما لا أفهمه هو سبب محاولة Mom تحميل ملف en-us إذا ، كما ورد في بعض التعليقات أعلاه ، يجب أن يعرف المُحمل أنه يحتوي بالفعل على "en" وليس استيراده ديناميكيًا.

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

وجود تقصير خفي هو مجموعة من المفاجآت ...

image

سأحصل على 👎 لهذا ولكن الحل الخاص بي كان تبديل moment مقابل dayjs . نظرًا لأنهم يشاركون نفس الوظيفة / تسمية API ، فقد كان الأمر بسيطًا مثل find all + replace all بالنسبة لي.

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات