Moment: en, en-US locales

Hay una configuración regional en , simplemente no viene en un archivo separado. Es muy aceptado por moment().locale() y 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 también funciona porque caminamos buscando una coincidencia menos específica y la configuración regional en es inglés de EE. UU.

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"

No lo compro; considere el caso en el que la configuración regional se detecta en el entorno, y luego se construye una ruta de depósito requerida para cargar moment / locale / $ {installedLocale}. Si esa variable es "en" o "en-us", requirejs no podrá cargar un archivo (obtiene un 404). Si se detecta como 'de', se cargará el archivo.

El cargador de configuración regional de @eigood Moment sabe que ya tiene inglés y no intenta cargarlo desde un archivo externo.

@icambron No creo que esté en lo correcto acerca de caminar por el árbol cuando el usuario pasa en 'en-US' como configuración regional. De hecho, actualmente lo estoy depurando y se está rompiendo porque NO estás caminando por el árbol.
Mi caso de uso es que estoy llamando a moment.utc (myDate, myFormat, locale, true) donde locale es solo una sola cadena 'en-US'. Dado que esa cadena no se puede importar (ya que no hay un archivo para ella) pero no es una matriz, intenta requerir la configuración regional y luego se interrumpe en los entornos de producción.
Me parece que el mejor comportamiento real sería incluir en-US en la lista de configuraciones regionales presentes de forma predeterminada (no está allí en este momento, solo en por sí solo).

@steveccable Bueno, intenta cargarlo, por si acaso tuvieras una localización más específica. Cuando falla, intenta simplemente "en" y tiene éxito. Creo que la desconexión es solo que de alguna manera, al no cargar "en-US", se está rompiendo. No se supone que nada explote aquí; se supone que debe fallar con gracia y pasar a la siguiente opción. Entonces tendrás que contarme más sobre tu entorno: ¿qué, específicamente, está fallando?

@icambron Mi entorno es una aplicación React Native que usa npm para controlar mis dependencias, y he podido replicar la falla incluso en aplicaciones de muestra mínimas. El problema es que en la función loadLocale, intenta requerir ('./ locale /' + nombre) donde el nombre es en-US, y ese requerimiento falla. Cuando ese requerimiento falla en una compilación de lanzamiento, hace que la aplicación se bloquee con un seguimiento de pila a lo largo de las líneas de lo siguiente:

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

Mirando a través del código, dado que getLocale ve que mi clave ('en-US') no es una matriz, cae en loadLocale sin siquiera intentar hacer coincidir 'en', lo que solo sucedería si entrara en la función chooseLocale.

EDITAR: Después de mirar un poco más de cerca la función chooseLocale, primero intentaría elegir 'en-US' y luego fallaría el requerimiento antes de intentar 'en', por lo que el requerimiento fallido que conduce a una aplicación que falla aún se produciría si se trataba de una matriz.
También es extraño el hecho de que el lugar donde se rompe está dentro de un try / catch, pero causa un choque de todos modos. Eso es realmente lo realmente desconcertante aquí.

EDITAR 2: Tenga en cuenta que el require falla correctamente cuando está en una compilación de depuración (__DEV__) y luego se reduce al uso de 'en'. No estoy seguro de por qué require es mucho más explosivo en __PROD__, pero definitivamente se está rompiendo aquí en el momento.

EDICIÓN 3: De los documentos de require js, "Si no expresa las dependencias, es probable que obtenga errores de carga ya que RequireJS carga scripts de forma asincrónica y fuera de orden para la velocidad". Por lo tanto, es poco probable que try / catch nos salve aquí, ya que try / catch solo ayuda con los errores sincrónicos.

Entonces, después de trabajar un poco, tengo una solución (menos que ideal). Básicamente, cada vez que mi código intenta pasar en una configuración regional de 'en-US', lo intercepto y paso en una configuración regional de 'en' en su lugar. Se permite que otras configuraciones regionales pasen sin cambios.

Dicho esto, sigo pensando que es problemático que no pueda encontrar en-US ni que ya lo tenga de forma predeterminada, y no puede incluirlo específicamente como puede hacerlo con otras configuraciones regionales para evitar no encontrarlo cuando realmente se llama. sobre.

@steveccable

También es extraño el hecho de que el lugar donde se rompe está dentro de un try / catch, pero causa un choque de todos modos. Eso es realmente lo realmente desconcertante aquí.

Bien, eso es lo que estoy diciendo. Estoy tratando de entender por qué una llamada de solicitud fallida sería catastrófica. No ayudaría a codificar en el conocimiento de en-US ; todavía tendríamos una falla similar en cualquier otro caso alternativo. es decir, eso no tiene nada que ver con que en sea ​​un caso especial, sino que tiene que ver con que el proceso de reserva no funciona en absoluto en su entorno.

Trabajando a través de él, parece que React Native no está manejando los requisitos fallidos con tanta elegancia como nos gustaría. Tiene razón en que no tiene nada que ver con que en es un caso especial, y la única razón por la que parecía que era especial fue porque no había forma de evitar que fallara el requerimiento en-US (ya que no podemos importarlo directamente como con otras configuraciones regionales). Como se menciona en la edición posterior, try / catch no funciona porque falla de forma asincrónica.
Por ahora, la solución que mencioné anteriormente de simplemente desinfectar las configuraciones regionales de 'en-US' funciona para mis propósitos.

el intento / captura no funciona porque falla de forma asincrónica

Oh, me perdí esa edición. Esa también iba a ser mi suposición.

@steveccable
No estoy seguro de si todavía tiene el problema, pero exactamente los mismos bloqueos en la versión de lanzamiento (aunque con la configuración regional francesa) consumieron un día de trabajo para mí 😢

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

Lo resolví con:

import 'moment/locale/fr';

Tal vez ayude

La solución alternativa de desinfectar la entrada de la configuración regional está bien, pero es realmente aterrador saber que un require () nativo de reacción puede fallar de forma asincrónica en cualquier lugar y no hay forma de detectarlo. Además, si envío una configuración regional no existente o una cadena aleatoria (diga 'bla-bla') eso significa que la aplicación se bloquea y no puedo manejar el error en ninguna parte. Así que tengo que estar comprobando a la defensiva que nadie desencadena este error.

Tuve problemas después de la versión 2.19.2, esto es lo que cambió con esa versión https://github.com/moment/moment/compare/29afed6...328d51e la función updateLocale comenzó a usar loadLocale internamente, lo que a su vez requiere con una cadena dinámica https : //github.com/moment/moment/blob/fea48bb69eda8c0459915d6aa66a910a4d43a55b/moment.js#L1845

Supongo que esto falla en reaccionar nativo porque allí no puede requerir archivos dinámicamente por variable https://github.com/facebook/react-native/issues/6391

En mi caso específico, estoy importando el archivo en-gb, por lo que debería encontrarse en locales[name] para cuando llame a moment.locale. No estoy seguro de por qué no es necesario.

No estoy seguro de que RN sea una prioridad o no, pero el momento para RN se romperá durante meses.

Con todo esto, parece que Facebook # 69 es la solución más productiva para desbloquear a todos. Hablaré con @jeanlauliac y veremos si podemos fusionarlo el lunes.

Solo para dar algunos antecedentes: hay varias razones por las que no admitimos dependencias dinámicas. Primero, el análisis estático se interrumpe cuando se requieren módulos dinámicamente. En segundo lugar, cuando se utilizan requisitos dinámicos, es posible que el módulo real que está buscando no esté disponible. Esto puede causar problemas importantes en la producción que evitarían que los usuarios usen nuestras aplicaciones, como por ejemplo, podríamos romper Facebook. Tuvimos problemas como este en el pasado y no es divertido lidiar con ellos. Metro tiene una opinión intencional para evitar que las personas hagan cosas que causarán dolor a los usuarios.

Finalmente, entendemos que este repositorio de código abierto no está en muy buena forma en este momento. La buena noticia es que nunca ha habido más gente en FB trabajando en Metro, y tenemos una serie de cambios importantes en la tienda para hacer que Metro sea mucho mejor, pero la mala noticia es que hay problemas urgentes que debemos resolver sin relación. al código abierto. Esperamos que en un par de meses este repositorio esté en un estado mucho mejor y en el que sea más fácil contribuir. Danos algo de tiempo por favor.

Para RN, lo hice funcionar en modo de lanzamiento al quitar la primera parte de la configuración regional (probablemente qué momento ocurre detrás de las pantallas cuando no se carga la configuración regional "xx-XX"). En el siguiente fragmento, locale es la configuración regional de su dispositivo en el formato "xx-XX".

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

Este es un comportamiento extraño.

https://stackoverflow.com/a/47260841/175825 necesita importar una configuración regional específica para que el ecosistema pueda consumirlos.

Debido a esta magia, no puedo hacer que react-big-calendar muestre fechas como mm/yy usando BigCalendar.momentLocalizer() porque espera que se cargue la configuración regional.

Podría abrir un problema con react-big-calendar, pero ¿qué pasa con la próxima biblioteca con la que me encuentro que espera una configuración regional específica? ¿Y el siguiente?

Simplemente agregue la configuración regional en-us y el valor predeterminado es mágico.

Simplemente agregue la configuración regional en-us y el valor predeterminado es mágico.

No resolverá el problema, hay idiomas como el español ( es-ES => es ) que hacen retroceso automático.

Para cualquiera que todavía esté buscando una solución, esto puede ayudar a mitigar el problema (con la excepción de algunos casos extremos) pero no solucionará el problema raíz de RN que causa un bloqueo durante el 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'; 
};

También experimenté este problema al usar React Native y pude evitarlo al incluir todas las configuraciones regionales junto con Moment, es decir,

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

(Alternativamente, también se proporciona moment/min/moment-with-locales pero no era compatible con algunos de nuestros otros formateadores).

Este es un tema muy molesto.

¿No es el objetivo de las configuraciones regionales que ni siquiera tienes que pensar en ello, y ciertamente no estar codificando 'en-US' en tu código solo porque TÚ estás en EE. UU.? No entiendo por qué cuando solicito una configuración regional de 'en-US' no puede simplemente tomarlo. Causa a la gente sin fin de dolores de cabeza.

Resolví este problema hace un año pero olvidé completamente cómo, entonces tengo que empezar de nuevo. (Estoy usando un selector de fecha en Angular y solo estoy poniendo la implementación mínima en explosiones con este error).

Recibo esto en Angular tratando de usar el selector de fecha y hora. Si configuro LOCALE en algo como en-GB, funciona bien, pero sin especificar nada, obtengo esto. Ojalá pudiera encontrar la forma correcta de solucionar este problema.

Para RN, lo hice funcionar en modo de lanzamiento al quitar la primera parte de la configuración regional (probablemente qué momento ocurre detrás de las pantallas cuando no se carga la configuración regional "xx-XX"). En el siguiente recorte, locale es la configuración regional de su dispositivo en el formato "xx-XX".

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

Esta solución funciona para mí, usando i18n y momentjs así:

// 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('-')));

Todavía estoy experimentando este problema con la versión "moment": "^ 2.22.2",
¿Alguna corrección en la última versión?

Voy a intervenir en este tema.

1. tratar en-US como una forma diferente predeterminada oculta de los demás es un mal diseño.
2. sin configuración regional en-us, no sé qué versión de CDN usar.
3. Moment parece impresionante, pero encontraré otra solución, ya que en-US no es el mismo que otras configuraciones regionales es un mal olor a código.

También tuve este error en react-native en producción después de hacer un buen desarrollo construido que funciona perfectamente.
Lo solucioné con la solución que propuso @adesmet y el siguiente refactor:

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

Parece que RN apesta tanto con el momento que es más fácil escribir un formateador nativo. Probablemente solo una línea de código, a prueba de balas para que funcione.

Terminé arreglándolo así:

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);

con react native @tapz, lamentablemente, esto parece funcionar en Android, pero en iOS, lamentablemente: / Tengo algunos problemas con la configuración regional zh por algunas razones: /

Eso podría deberse a que zh y algunas otras configuraciones regionales tienen un formato diferente para diferenciar entre simplificado y tradicional. Ver https://gist.github.com/jacobbubu/1836273

@ rajivshah3 de hecho estaba teniendo zh_Hant_HK que no funcionaba con el método tapz. Ahora estoy usando su método, que parece la mejor manera de lidiar con este problema de la manera más fluida posible gracias por su publicación

El mismo problema, solo en el modo de producción RN.

Esto parece funcionar bien para mí.

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;
};

Siempre que los datos se importen (o en ) y se respete el caso, parece funcionar bien para nosotros

Esto es realmente ridículo. Eliminar la sección -region del código de idioma no es una solución.

1) Pierde la especificidad regional de la localidad.
2) Peor aún, ese método provocará más fallas. El chino ( zh ), por ejemplo, ni siquiera existe en las configuraciones regionales de MomentJS. Solo se definen zh-cn , zh-hk y zh-tw . Entonces, si está utilizando el código anterior para eliminar regiones de la cadena de configuración regional, su aplicación se bloqueará inmediatamente en la mayoría de los dispositivos chinos. Solo unos miserables ~ 800 millones de usuarios de teléfonos inteligentes.

Mi solución temporal (y absolutamente loca) para React Native es esta:

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 Hola, ¿tenemos alguna noticia sobre la corrección de las configuraciones regionales de momento para RN?

Esto acaba de fallar en una versión de lanzamiento en este momento usando en-gb .

Tengo un problema similar al de; @simeyla .

Cuando agregué Luxon junto con los problemas de timepicker, aparecen y parecen estar relacionados con la configuración regional 'en-US'.

@steveccable Bueno, intenta cargarlo, por si acaso tuvieras una localización más específica. Cuando falla, intenta simplemente "en" y tiene éxito. Creo que la desconexión es solo que de alguna manera, al no cargar "en-US", se está rompiendo. No se supone que nada explote aquí; _Se supone que debe fallar con gracia_ y pasar a la siguiente opción. Entonces tendrás que contarme más sobre tu entorno: ¿qué, específicamente, está fallando?

Otro problema con el manejo de 'en-US' u otras configuraciones regionales válidas con excepciones es que cuando está depurando y le pide al depurador que frene las excepciones, se queda atascado en esta repetidamente.

Debería haber una forma mejor y más sencilla, especialmente para un lugar tan grande como 'en-US'.
Eventualmente, estos lugares con posibilidad de gran audiencia / uso deben revisarse y tratarse al principio, para considerar la velocidad.

Modifiqué la solución de

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"

El mismo problema, solo en el modo IOS de producción de RN.

Esto parece funcionar bien para mí.

importar momento desde "momento";
importar 'momento / configuración regional / es';

Pasé bastante tiempo depurando esto, gracias @jorodriguez por esto

Esto sigue siendo un problema 😢

Hola chicos,

He creado un pequeño paquete para ti -> https://github.com/tonix-tuft/moment-utl

npm install --save moment moment-utl

Puede utilizar lo siguiente para determinar todas las configuraciones regionales admitidas de momento sin la necesidad de cargarlas por adelantado:

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 depende de moment , pero agrupa todos los moment locales
tomándolos del directorio moment/locale durante su construcción, un paquete de dependencia moment dev.

Sin embargo, como moment es una dependencia de pares, si está usando ES6 y quiere asegurarse de que allSupportedLocales y allSupportedLocalesMap ambos usen configuraciones regionales actualizadas con moment versión que ha instalado en su proyecto junto con moment-utl (por ejemplo, si moment agrega una nueva configuración regional algún día, entonces esto debería cubrirlo), entonces también puede regenerar esas configuraciones regionales usando el moment-utl-locales script proporcionado por moment-utl .

Puede usarlo con el comando 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

Cuando use este script, asegúrese de ejecutarlo antes de empaquetar su código con Rollup o Webpack (cualquiera que use), de modo que generará una matriz y un objeto de configuraciones regionales actualizadas antes de que su empaquetador los encuentre y los agregue a tu paquete final.

¡Espero que esto ayude!

En respuesta a @adammcarth , verifique mi respuesta aquí: https://github.com/tonix-tuft/moment-utl/issues/1#issuecomment -616088826

Este problema ha perseguido a los chicos de Odoo y la solución sugerida fue crear el archivo en-us manualmente. Suspiro.

Lo que no entiendo es por qué moment intenta cargar el archivo en-us si, como se dijo en algunos comentarios arriba, el cargador debe saber que ya tiene "en" y no lo importa dinámicamente.

De todos modos, sigue siendo una pesadilla para los usuarios de RN. La peor parte es que el problema solo ocurre en las compilaciones de producción.

Tener un defecto oculto es un paquete de sorpresas ...

Este problema ha perseguido a los chicos de Odoo y la solución sugerida fue crear el archivo en-us manualmente. Suspiro.

Lo que no entiendo es por qué moment intenta cargar el archivo en-us si, como se dijo en algunos comentarios arriba, el cargador debe saber que ya tiene "en" y no lo importa dinámicamente.

De todos modos, sigue siendo una pesadilla para los usuarios de RN. La peor parte es que el problema solo ocurre en las compilaciones de producción.

Tener un defecto oculto es un paquete de sorpresas ...

Voy a obtener 👎 para esto, pero mi solución fue intercambiar moment por dayjs . Como comparten la misma función / nombre de API, fue tan simple como find all + replace all para mí.

Solo comparto lo que hice por las personas que quieran considerar esto.