c# - number - formato moneda reporting services

WinRT aplicaciones y configuración regional. ¿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 y 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 de EE. UU. ¿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 solo imprime el CurrentCulture y el DateTime formateado. Ahora:

    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 muestra la fecha en formato finlandés:

Luego cambié la configuración regional a EE. UU .:

Y cuando la aplicación se ejecutó de nuevo, la cultura y el formato cambiaron:

Esto es como esperaba que todo funcionara y así también esperaba que las aplicaciones WinRT funcionaran.

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 a 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 el formato de EE. UU. Luego modifiqué el archivo de proyecto de la aplicación e hice fi-FI el idioma predeterminado :

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é carpetas "Strings - fi-FI" dentro del proyecto y agregué un "Resources.resw" vacío al proyecto . Este archivo vacío parece ser suficiente, ya que ahora recibía el formato finlandés:

Tan pronto como elimine el archivo de recursos vacío, los formateos vuelven a los EE. UU .:

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 el ejemplo que se da aquí: http://code.msdn.microsoft.com/windowsapps/Globalization-preferences-6654eb36/sourcecode?fileId=52104&pathId=236099476

Answer 2

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 3

Esta publicación todavía parece relevante a pesar de haber sido solicitada hace dos años. Me encontré con que 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 se me ocurrió y parece funcionar 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;
}

Answer 4

Ha pasado un tiempo, pero la pregunta no está completamente respondida, 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 intencional. 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 la región actual, podemos usar:

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

Pero como noté que solo contiene información de la región, no hay un código de idioma. Para obtener un lenguaje podemos usar:

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)

Devuelven las etiquetas de idioma BCP47 en formato de lenguaje-REGION como "en-US" si el idioma tiene dialectos o solo un idioma como "pl" si el idioma no tiene dialectos principales.

También podemos establecer un idioma principal que anulará todo el resto:

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

(Esta es una configuración persistente y se supone que debe usarse a solicitud del usuario)

También hay una nueva API para fecha, hora y números:

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

Realmente hay mucho más en Windows.Globalization APIs, pero creo que esto nos da la idea general. Para lectura adicional:

• Muestra de formato de fecha y hora: http://code.msdn.microsoft.com/windowsapps/Date-and-time-formatting-2361f348/sourcecode?fileId=52070&pathId=561085805
• número de formato y muestra de 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 usar patrones para formatear fechas y horas" en msdn, pero puedo agregar solo 2 enlaces.

También puede encontrar algunos temas sobre el tema en el foro del centro de desarrolladores de Windows 8 con algunas respuestas de los empleados de Microsoft, pero principalmente lo envían a la documentación.