WinRT aplicaciones y configuraciones regionales. ¿La forma correcta de formatear fechas y números en función de la configuración regional del usuario?

Question

Tengo algunos problemas en las aplicaciones Metro de Windows 8 (XAML & C#) con respecto a la configuración regional del usuario. Parece que las aplicaciones no respetarán la configuración regional del usuario, por lo que incluso si su Windows 8 está configurado para mostrar las fechas y horas en formato finlandés, las aplicaciones todavía las mostrarán utilizando el formato US. ¿Pero este es un problema tan grande que debe haber algo que me falta?

Para probar esto comencé creando una aplicación WPF. La aplicación se limita a imprimir la CurrentCulture y la DateTime.Now formato:

private void Culture_Loaded_1(object sender, RoutedEventArgs e) 
    { 
     this.Culture.Text = System.Globalization.CultureInfo.CurrentCulture.DisplayName; 
    } 

    private void Date_Loaded_1(object sender, RoutedEventArgs e) 
    { 
     this.Date.Text = DateTime.Now.ToString(); 
    } 

Aquí está mi configuración regional predeterminada:

Cuando se ejecuta, la aplicación mostrará la fecha en formato de Finlandia:

Entonces cambió la configuración regional de los Estados Unidos:

Y cuando la aplicación se ejecuta de nuevo, la cultura y el formato cambió:

Ésta es como esperaba todo para trabajar y esta es también la forma en que esperaba aplicaciones WinRT para trabajar.

Así que, como paso siguiente, creé una aplicación WinRT (XAML & C#) con el mismo código y revertí la configuración regional de nuevo al finlandés. El problema:

Incluso cuando he definido a través de la configuración regional que el formato debe ser "finlandés", la aplicación WinRT muestra la fecha y hora con Estados Unidos y el formato. luego modifiqué archivo de proyecto de la aplicación e hice fi-FI el idioma por defecto:

Este cambio también modificó la cultura de la aplicación:

extraño. Cambié el idioma predeterminado a su valor predeterminado y el formato se restauró en EE. UU. Luego creé las carpetas "Strings - fi-FI" dentro del proyecto y agregué un vacío "Resources.resw" al proyecto. Este archivo vacío parece ser suficiente, ya que ahora estaba recibiendo el formato de Finlandia:

Tan pronto como se quita el archivo de recursos vacía, los formateos revierte de nuevo a los Estados Unidos:

Muy extraño.

Esto lleva a algunas preguntas, pero la principal es: ¿Es intencional que las aplicaciones WinRT no sigan las configuraciones regionales del usuario como lo hacen las aplicaciones WPF?

Answer 1

¿Podría ser que ahora necesitamos consultar otras clases? Como en el ejemplo dado aquí: http://code.msdn.microsoft.com/windowsapps/Globalization-preferences-6654eb36/sourcecode?fileId=52104&pathId=236099476

Answer 2

Ha pasado un tiempo, pero la pregunta no ha sido respondida por completo, así que permítanme compartir mi pequeña investigación. Depechie tiene la razón, pero él solo proporcionó un enlace y no estaba realmente seguro.

Sí, este cambio inesperado es intencionado. No deberíamos utilizar CultureInfo ya que contiene códigos heredados y Microsoft quiere que usemos las API de Windows.Globalization en su lugar.

Para obtener región actual podemos utilizar:

GeographicRegion userRegion = new GeographicRegion(); 
string regionCode = userRegion.CodeTwoLetter; 

Pero como me di cuenta que sólo contiene información de la región, no hay código de idioma. Para obtener el lenguaje podemos utilizar:

string langRegionCode = Windows.Globalization.Language.CurrentInputMethodLanguageTag; // depends on keyboard settings 
List<string> langs = Windows.System.UserProfile.GlobalizationPreferences.Languages; // all user languages, like in languages control panel 
List<string> applicationlangs = Windows.Globalization.ApplicationLanguages.Languages; // application languages (user languages resolved against languages declared as supported by application) 

Vuelven BCP47 etiquetas de idioma en formato de lenguaje-región como "en-US" si el lenguaje tiene dialectos o idiomas al igual que "pl" si el idioma no tiene dialectos principales .

Nosotros también puede establecer un idioma primario que anulará todos los demás:

Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = "en-US"; 

(Esta es una configuración persistió y se supone que debe ser utilizado a petición del usuario)

También hay nueva API para la fecha, hora y número:

Windows.Globalization.DateTimeFormatting.DateTimeFormatter dtf = new DateTimeFormatter("longdate", new[] { "en-US" }, "US", CalendarIdentifiers.Gregorian, ClockIdentifiers.TwentyFourHour); 
string longDate = dtf.Format(DateTime.Now); 

Windows.Globalization.NumberFormatting.DecimalFormatter deciamlFormatter = new DecimalFormatter(new string[] { "PL" }, "PL"); 
double d1 = (double)deciamlFormatter.ParseDouble("2,5"); // ParseDouble returns double?, not double 

No hay realmente mucho más en las API Windows.Globalization, pero creo que esto nos da la idea general. Para la lectura adicional:

• fecha & para formatear el tiempo de la muestra: http://code.msdn.microsoft.com/windowsapps/Date-and-time-formatting-2361f348/sourcecode?fileId=52070&pathId=561085805
• formato de número de muestras & análisis:
  http://code.msdn.microsoft.com/windowsapps/Number-formatting-and-bb10ba3d/sourcecode?fileId=52249&pathId=1462911094
• también hay un buen artículo titulado "Cómo utilizar patrones para formatear fechas y horas" en msdn, pero puedo agregar solo 2 enlaces

También puede encontrar algunos temas sobre el problema en windo ws 8 dev center forum con algunas respuestas de los empleados de Microsoft, pero principalmente lo envían a la documentación.

Answer 3

Es intencional. Microsoft se está alejando de obligar a las aplicaciones a estar en el lenguaje del sistema operativo. En cambio, cada aplicación usa información declarada por la aplicación (lenguajes de manifiesto, observables en Windows.Globalization.ApplicationLanguages.ManifestLanguages) y declarada por el usuario (lenguajes de usuario, observables en Windows.System.UserProfile.GlobalizationPreferences.Languages) para determinar cómo mostrar recursos y fechas y horarios globalizados. Este conjunto de idiomas se denomina lenguajes de la aplicación (observable en Windows.Globalization.ApplicationLanguages.Languages). El comportamiento que está viendo se debe a que está jugando con los idiomas de usuario y los lenguajes de manifiesto, y obtendrá diferentes idiomas de aplicación.

Answer 4

Esta publicación sigue pareciendo relevante a pesar de haber sido solicitada hace dos años. Acabo de encontrarlo porque estaba buscando una respuesta sobre lo mismo. También quería mostrar las fechas en el formato regional en mi aplicación WP8.1 WinRT. La información publicada aquí ayuda, pero fue un poco difícil armarla.

Esto es lo que me ocurrió y parece que funciona para mí como la respuesta que necesitaba:

using Windows.Globalization; 
using Windows.Globalization.DateTimeFormatting; 

private string FormatDate(int year, int month, int day) 
{ 
    GeographicRegion userRegion = new GeographicRegion(); 
    string regionCode = userRegion.CodeTwoLetter; 
    var formatter = new DateTimeFormatter("year month day", new[] { regionCode }); 
    DateTime dateToFormat = new DateTime(year, month, day); 
    var formattedDate = formatter.Format(dateToFormat); 
    return formattedDate; 
}