Xamarin.forms: Visualización de fecha y hora enlazada en formato en-US, no en formato local

Me alegro de que finalmente se esté analizando esto. Se registró el 8 de septiembre de 2017. Fue reproducido originalmente por una persona de Xamarin al día siguiente. Esto afecta a todos los usuarios de Xamarin Forms fuera de EE. UU. Y a los usuarios de Xamarin Forms con clientes fuera de EE. UU.

@rmarinho # 2434 podría ser una víctima de esto, y puede que no. De cualquier manera, tenemos que solucionar este problema, ya que es un problema bastante extendido. Me complace enviar un PR si alguien puede dar una pequeña dirección sobre dónde abordarlo.

simplemente volviendo a tocar el timbre sobre este tema, es algo con lo que estamos luchando a diario en una aplicación multilingüe. Está listo para trabajar y hay gente dispuesta a ayudar y enviar PR, pero todavía estamos esperando instrucciones sobre cómo le gustaría que se resolviera.

Veo un problema similar al aplicar StringFormat a una entrada: consulte mi descripción detallada en el foro de Xamarin.Forms aquí . No está relacionado con Cultures, pero _ está_ relacionado con cómo la Entrada maneja el formato.

Creo que mi problema es sutilmente diferente al descrito en este número, pero relacionado. ¿Merece la pena agregar un nuevo número o agregar más detalles aquí?

Parece que este error ha existido durante mucho tiempo. Creo que la compatibilidad con varios idiomas es una función esencial de muchas aplicaciones. Actualmente, necesita algunas soluciones para lograr esto. Me gusta usar Xamarin.Forms y sería genial si este error se corrigiera pronto.

¡Gracias Xamarin Team por su gran trabajo!

Atentamente

He actualizado la dirección del repositorio en caso de que alguien tuviera problemas para recrear el problema.

Creo que la compatibilidad con varios idiomas es una función esencial de muchas aplicaciones.

¡Convenido! Si miras el PR que abrimos para mejorar esto (# 3700), verás que estamos luchando con cómo hacer esto de la mejor manera posible para evitar romper una gran cantidad de aplicaciones. ¡Estamos abiertos a sugerencias! ¡Gracias!

@samhouts

Mi dinero estaría en implementar la propiedad Language para poder optar por un idioma determinado. Entonces, el enlace se basaría en la propiedad Language si está establecida. Significa que una línea de código podría cambiar la aplicación a la configuración regional existente del usuario, pero no necesariamente cambiar ninguna funcionalidad existente en las aplicaciones existentes. Esa es la forma en que se hace en otras plataformas XAML. Supongo que esas plataformas tenían un problema similar con el que lidiar y el uso de ese patrón haría que Xamarin.Forms fuera más compatible con esas tecnologías.

Creo que la compatibilidad con varios idiomas es una función esencial de muchas aplicaciones.

¡Convenido! Si miras el PR que abrimos para mejorar esto (# 3700), verás que estamos luchando con cómo hacer esto de la mejor manera posible para evitar romper una gran cantidad de aplicaciones. ¡Estamos abiertos a sugerencias! ¡Gracias!

Mi 0.2 $ es que en .NET ya existe una funcionalidad diseñada para manejar el formato y el análisis: CultureInfo.CurrentCulture

Si cambia el formato de código DateTime a una cadena con DateTime.Now.ToString (), automáticamente usará CultureInfo.CurrentCulture para formatearlo. Lo mismo ocurre con el análisis de una cadena en un DateTime con DateTime.Parse: se usa CurrentCulture.
¿Por qué una conversión de enlace (formato) de DateTime -> string no debería producir el mismo resultado que cuando lo hace en su ViewModel? El desarrollador promedio se sorprende y se queda perplejo cuando arroja resultados diferentes. Y haga una simple búsqueda en Google para ver cuántas variaciones y soluciones existen como soluciones para este comportamiento, que el marco podría manejar fácilmente.

En este momento es un desastre donde los teclados en pantalla usan la configuración del dispositivo para la región, pero las cadenas de análisis / formato de código .NET están usando el idioma / cultura de visualización. En el caso de la interfaz de usuario en inglés y la región sueca, está escribiendo números con una "," (coma) como separador decimal y .NET intenta analizarlos usando "." (punto) como separador decimal.

Para atar cabos sueltos, Xamarin Forms debe crear un CultureInfo personalizado basado en la configuración de cada plataforma / dispositivo (por ejemplo, en iOS usando la configuración de Región), y asignarlo de forma predeterminada a CultureInfo.CurrentCulture, por lo que todos y cada uno de los desarrolladores, no Tengo que intentarlo.

Como desarrollador de WPF, se quedó perplejo cuando el enlace no se adhiere a lo que describí anteriormente (y lo considero un error) pero es fácil de resolver para WPF con
this.Language = XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag); .

No me hagas empezar con UWP, en el que parecen haber olvidado que la gente realmente quiere que la región / formato sea diferente al idioma de visualización (como quiere una gran parte del mundo) .

Me encontré con el mismo problema al vincular una entrada a una propiedad numérica. Es aún peor que el comportamiento sea diferente entre tipos:

CurrentCulture = de-de

Enlace del modelo a la interfaz de usuario:
La vinculación de una propiedad decimal da como resultado "10,41" (no se respeta la referencia cultural actual)
Vincular una propiedad flotante da como resultado "10,41"
La vinculación de una propiedad doble da como resultado "10,41" (no se respeta la referencia cultural actual)

, es decir, solo las propiedades flotantes se enlazan con la cultura correcta

Enlace de la interfaz de usuario al modelo:
solamente "." se reconoce como un separador válido independientemente del tipo de datos y la cultura.

Como primer paso, al menos unifique el comportamiento para todos los tipos de datos.
como segundo paso, agregue una solución de trabajo para que los desarrolladores vinculen valores numéricos correctamente de acuerdo con la cultura actual y hagan que los teclados numéricos en pantalla estén sincronizados con la cultura actual ...

¿Cómo puede un marco llegar a este punto, v4.4, y aún hacer que los decimales funcionen solo para en-US?
También tengo este problema y tengo que trabajar con cadena a decimal y decimal a cadena con todas mis propiedades decimales .....

¿Alguna noticia sobre esto?

El problema aún se puede reproducir en la última versión de Xamarin.Forms.
Hasta ahora, una solución es crear un IValueConverter para manejar esto.

¿Alguna información sobre cuándo se solucionará esto?

Vincular una fecha y hora a una etiqueta que espera una cadena debe ser un error de tipo, a menos que el usuario proporcione explícitamente una función.

Este problema surgió al migrar de Xamarin.Forms 3.6.0.344457 a 4.4.0.991757.

En nuestro caso, tenemos una entrada personalizada, donde reemplazamos la coma con un punto, de modo que cuando el usuario haga clic en la coma en el teclado virtual, se reemplazará por un punto.

Solución extraña, lo sé, pero solía funcionar en 3.6.0.344457, pero no en 4.4.0.99175. ¿Que ha cambiado? Mirando el historial de problemas, puedo ver que se hizo algo de trabajo en la v3.6.0. Parece que es un error de regresión.

Este problema no parece haber tenido actividad en mucho tiempo. Estamos trabajando para priorizar los problemas y resolverlos lo más rápido posible. Para ayudarnos a completar la lista, agradeceríamos una actualización de su parte para informarnos si esto todavía lo está afectando en la última versión de Xamarin.Forms, ya que es posible que hayamos resuelto esto como parte de otro relacionado o duplicado problema. Si no vemos ninguna actividad nueva sobre este problema en los próximos 30 días, evaluaremos si este problema debe cerrarse. ¡Gracias!

Sí, todavía afecta a la última versión 4.8.