Moment: в, местный в США

Есть локаль 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"

Я не куплюсь на это; рассмотрим случай, когда локаль определяется из среды, а затем создается путь require dep для загрузки момента / locale / $ {detectLocale}. Если эта переменная - «en» или «en-us», то requirejs не сможет загрузить файл (получит 404). Если обнаруживается , как «де», то файл будет загружен.

Загрузчик локали

@icambron Я не думаю, что вы правы, идя вниз по дереву, когда пользователь переходит в «en-US» в качестве локали. Фактически, я сейчас отлаживаю его, и он ломается, потому что вы НЕ идете по дереву.
Мой вариант использования заключается в том, что я вызываю moment.utc (myDate, myFormat, locale, true), где locale - это всего лишь одна строка «en-US». Поскольку эта строка не может быть импортирована (поскольку для нее нет файла), но это не массив, она пытается потребовать языковой стандарт, а затем прерывается в производственной среде.
Мне кажется, что лучше всего было бы включить en-US в список локалей, присутствующих по умолчанию (сейчас его нет, просто en сам по себе).

@steveccable Ну, он пытается его загрузить, на случай, если у вас была более конкретная локализация. Когда это не удается, он пытается просто "en" и добивается успеха. Я думаю, что отключение связано с тем, что почему-то вам не удается загрузить "en-US". Здесь ничего не должно взорваться; он просто должен изящно провалиться и перейти к следующему варианту. Так что вам придется рассказать мне больше о своем окружении: что конкретно происходит не так?

@icambron Моя среда - это приложение React Native, использующее npm для управления моими зависимостями, и я смог воспроизвести сбой даже в минимальных примерах приложений. Проблема в том, что в функции loadLocale она пытается требовать ('./ locale /' + name), где 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', что могло бы произойти только в том случае, если бы он перешел в функцию selectLocale.

РЕДАКТИРОВАТЬ: после более внимательного взгляда на функцию selectLocale, она все равно сначала попытается выбрать «en-US», а затем не выполнит требование, прежде чем пытаться «en», поэтому неудачное требование, приводящее к сбою приложения, все равно произойдет если бы это был массив.
Также странным является тот факт, что место, где он ломается, находится внутри try / catch, но все равно вызывает сбой. На самом деле это действительно сбивает с толку.

РЕДАКТИРОВАТЬ 2: Обратите внимание, что при сборке отладки (__DEV__) требование корректно завершается сбоем, а затем оно падает до использования 'en'. Я не уверен, почему require настолько взрывоопасен в __PROD__, но сейчас он определенно ломается.

РЕДАКТИРОВАТЬ 3: Из документации require js: «Если вы не укажете зависимости, вы, вероятно, получите ошибки загрузки, поскольку RequireJS загружает скрипты асинхронно и не по порядку для скорости». Так что try / catch вряд ли нас спасет, поскольку try / catch действительно помогает только с синхронными ошибками.

Итак, немного поработав с этим, у меня есть обходной путь (далеко не идеальный). В принципе, всякий раз, когда мой код пытается передать локаль en-US, я перехватываю его и вместо этого передаю локаль en. Остальные языковые стандарты разрешены без изменений.

Тем не менее, я все еще думаю, что проблематично то, что он не может ни найти en-US, ни по умолчанию уже имеет его, и вы не можете включить его специально, как вы можете с другими языками, чтобы избежать невозможности найти его, когда он фактически вызывается на.

@steveccable

Также странным является тот факт, что место, где он ломается, находится внутри try / catch, но все равно вызывает сбой. На самом деле это действительно сбивает с толку.

Верно, вот что я говорю. Я пытаюсь понять, почему невыполненный вызов require будет катастрофическим. Я бы не помогал жестко кодировать, зная en-US ; у нас все равно будет подобный сбой в любом другом резервном случае. т.е. это не имеет ничего общего с тем, что en является особым случаем, а скорее связано с тем, что резервный процесс вообще не работает в вашей среде.

Проработав это, выяснилось, что React Native не обрабатывает сбойные требования настолько изящно, насколько нам хотелось бы. Вы правы, что это не имеет ничего общего с en, являющимся особым случаем, и единственная причина, по которой он казался особенным, заключалась в том, что не было возможности предотвратить сбой требования en-US (поскольку мы не можем импортировать его напрямую как и в других регионах). Как упоминалось в более позднем редактировании, try / catch не работает, потому что он не работает асинхронно.
На данный момент упомянутый выше обходной путь простой очистки локалей en-US работает для моих целей.

try / catch не работает, потому что он не работает асинхронно

О, я пропустил эту правку. Это тоже было моим предположением.

@steveccable
Не уверен, есть ли у вас проблема, но точно такие же сбои в выпускной сборке (хотя и с французской локалью) отняли у меня день работы 😢

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

Я решил это с помощью:

import 'moment/locale/fr';

Может это поможет

Обходной путь дезинфекции ввода языкового стандарта - это нормально, но действительно страшно знать, что собственный алгоритм реакции require () может асинхронно завершиться с ошибкой в ​​любом месте, и это невозможно уловить. Кроме того, если я отправлю несуществующий языковой стандарт или случайную строку (скажем, «бла-бла»), это означает, что приложение выйдет из строя, и я не могу нигде обработать ошибку. Поэтому я должен защищаться, проверяя, чтобы никто не запускал эту ошибку.

У меня возникли проблемы после версии 2.19.2, вот что изменилось в этом выпуске https://github.com/moment/moment/compare/29afed6...328d51e функция updateLocale начала использовать loadLocale внутри, которая, в свою очередь, использует require с динамической строкой https : //github.com/moment/moment/blob/fea48bb69eda8c0459915d6aa66a910a4d43a55b/moment.js#L1845

Я предполагаю, что это не работает, потому что вы не можете динамически требовать файлы с помощью переменной https://github.com/facebook/react-native/issues/6391

В моем конкретном случае я импортирую файл en-gb, поэтому он должен быть найден в locales[name] к моменту вызова moment.locale. Я не уверен, почему это не удается.

не уверен, что РН в приоритете или нет, но момент для РН будет сломан на месяцы.

При всем этом кажется, что 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, вам необходимо импортировать конкретный языковой стандарт для экосистемы, чтобы иметь возможность их использовать.

Из-за этой магии я не могу заставить response-big-calendar отображать такие даты, как mm/yy используя BigCalendar.momentLocalizer() потому что он ожидает загрузки любого языкового стандарта.

Я мог бы открыть проблему с помощью response-big-calendar, но как насчет следующей библиотеки, с которой я столкнусь, ожидающей определенного языкового стандарта? А следующий?

Просто добавьте en-us locale и по умолчанию используйте magic.

Просто добавьте локаль en-us и по умолчанию - magic.

Это не решит проблему, есть такие языки, как испанский ( es-ES => es ), которые выполняют автоматический откат.

Для тех, кто все еще ищет решение, это может помочь смягчить проблему (за исключением нескольких крайних случаев), но не решит основную проблему RN, вызывающую сбой во время try-catch 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, он работает нормально, но без указания чего-либо, я получаю это. Хотел бы я найти правильный способ исправить это

Для 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('-')));

Я все еще экспериментирую с этой проблемой, используя версию "moment": "^ 2.22.2",
Есть исправления в последней версии?

Я вмешаюсь в эту проблему.

1. рассматривать en-US как некоторые скрытые значения по умолчанию, отличные от других, - это плохой дизайн.
2. без локали en-us я не знаю, какую версию CDN использовать.
3. Moment выглядит впечатляюще, но я не могу найти другое решение, поскольку en-US не такой, как другие локали, - это плохой запах кода.

У меня также была эта ошибка в react-native при производстве после создания хорошей разработки, которая отлично работает.
Решил это с помощью решения @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);

с реакцией родного локалью 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 .

У меня проблема, аналогичная проблеме: @simeyla .

Когда я добавил Luxon вместе с timepicker, появляются проблемы, которые, похоже, связаны с локалью 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.

Мне кажется, это нормально работает.

момент импорта из «момента»;
import 'moment / locale / es';

Некоторое время потратил на отладку, спасибо @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 peer зависит от moment , но объединяет все локали moment
взяв их из каталога moment/locale во время сборки пакета зависимостей moment dev.

Однако, поскольку 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 вручную. Вздох.

Я не понимаю, почему момент пытается загрузить файл en-us, если, как сказано в некоторых комментариях выше, загрузчик должен знать, что он уже имеет «en», а не импортировать его динамически.

Во всяком случае, это все еще кошмар для пользователей RN. Хуже всего то, что проблема возникает только в производственных сборках.

Наличие скрытого значения по умолчанию - это пакет сюрпризов ...

Эта проблема преследовала ребят из Odoo, и предложенное решение заключалось в том, чтобы создать файл en-us вручную. Вздох.

Я не понимаю, почему момент пытается загрузить файл en-us, если, как сказано в некоторых комментариях выше, загрузчик должен знать, что он уже имеет «en», а не импортировать его динамически.

Во всяком случае, это все еще кошмар для пользователей RN. Хуже всего то, что проблема возникает только в производственных сборках.

Наличие скрытого значения по умолчанию - это пакет сюрпризов ...

Я собираюсь получить 👎 для этого, но мое решение заменяло moment out на dayjs . Поскольку они используют одно и то же имя функции / API, для меня это было так же просто, как find all + replace all .

Просто делюсь тем, что я сделал, для людей, которые, возможно, захотят это рассмотреть.