Compartir a través de

Procedimientos recomendados para desarrollar aplicaciones listas para el mundo

En esta sección se describen los procedimientos recomendados que se deben seguir al desarrollar aplicaciones listas para el mundo.

Procedimientos recomendados de globalización

  1. Convierta la aplicación en Unicode internamente.

  2. Use las clases compatibles con la referencia cultural proporcionadas por el System.Globalization espacio de nombres para manipular y dar formato a los datos.

    • Para ordenar, use la SortKey clase y la CompareInfo clase .
    • Para comparaciones de cadenas, use la CompareInfo clase .
    • Para el formato de fecha y hora, use la DateTimeFormatInfo clase .
    • Para el formato numérico, use la NumberFormatInfo clase .
    • En el caso de los calendarios gregorianos y no gregorianos, use la Calendar clase o una de las implementaciones de calendario específicas.

  3. Utilice las configuraciones de propiedades de las referencias culturales proporcionadas por la clase System.Globalization.CultureInfo en las situaciones apropiadas. Use la CultureInfo.CurrentCulture propiedad para dar formato a las tareas, como la fecha y la hora o el formato numérico. Use la CultureInfo.CurrentUICulture propiedad para recuperar recursos. Tenga en cuenta que las propiedades CurrentCulture y CurrentUICulture se pueden establecer por subproceso.

  4. Permitir que la aplicación lea y escriba datos en y desde una variedad de codificaciones mediante las clases de codificación en el System.Text espacio de nombres. No presuma que los datos son ASCII. Supongamos que los caracteres internacionales se proporcionarán en cualquier lugar en el que un usuario pueda escribir texto. Por ejemplo, la aplicación debe aceptar caracteres internacionales en nombres de servidor, directorios, nombres de archivo, nombres de usuario y direcciones URL.

  5. Al usar la UTF8Encoding clase , por motivos de seguridad, use la característica de detección de errores que ofrece esta clase. Para activar la característica de detección de errores, cree una instancia de la clase mediante el constructor que toma un throwOnInvalidBytes parámetro y establezca el valor de este parámetro trueen .

  6. Siempre que sea posible, controle las cadenas como cadenas completas en lugar de como una serie de caracteres individuales. Esto es especialmente importante al ordenar o buscar subcadenas. Esto evitará problemas asociados con el análisis de caracteres combinados. También puede trabajar con unidades de texto en lugar de caracteres únicos mediante la System.Globalization.StringInfo clase .

  7. Muestre texto utilizando las clases proporcionadas por el espacio de nombres System.Drawing.

  8. Para la coherencia entre sistemas operativos, no permita que la configuración del usuario invalide CultureInfo. Use el CultureInfo constructor que acepta un useUserOverride parámetro y establézcalo en false.

  9. Pruebe la funcionalidad de la aplicación en versiones internacionales del sistema operativo mediante datos internacionales.

  10. Si una decisión en materia de seguridad se basa en el resultado de una comparación de cadenas o un cambio en el uso de mayúsculas y minúsculas, use una operación de cadenas que no tenga en cuenta la referencia cultural. Esta práctica garantiza que el resultado no se vea afectado por el valor de CultureInfo.CurrentCulture. Vea la sección "Comparaciones de cadenas que usan la referencia cultural actual" de Procedimientos recomendados para usar cadenas para ver un ejemplo que muestra cómo las comparaciones de cadenas sensibles a la referencia cultural pueden generar resultados incoherentes.

  11. Para cualquier elemento que se utilice para el intercambio (por ejemplo, un campo de un documento JSON en una llamada API) o el almacenamiento, use CultureInfo; además, debe especificar explícitamente un formato de ida y vuelta (como el especificador de formato de fecha y hora "O", "o"). Aunque las cadenas de formato de la referencia cultural invariable son estables y es poco probable que cambien, especificar una cadena de formato explícita ayuda a aclarar la intención del código.

  12. Los datos de globalización no son estables y debe escribir la aplicación y sus pruebas teniendo esto en cuenta. Se actualiza varias veces al año a través de canales del sistema operativo host en todas las plataformas compatibles. Normalmente, estos datos no se distribuyen con el tiempo de ejecución.

Procedimientos recomendados de localización

  1. Traslade todos los recursos localizables a archivos DLL independientes que sean sólo de recursos. Los recursos localizables incluyen elementos de la interfaz de usuario, como cadenas, mensajes de error, cuadros de diálogo, menús y recursos de objetos incrustados.

  2. No codifique cadenas ni recursos de la interfaz de usuario.

  3. No incluya recursos no localizables en archivos DLL que sean solo de recursos. Esto confunde a los traductores.

  4. No use cadenas compuestas que se compilan en tiempo de ejecución a partir de frases concatenadas. Las cadenas compuestas son difíciles de localizar porque a menudo asumen un orden gramatical en inglés que no se aplica a todos los idiomas.

  5. Evite construcciones ambiguas como "Carpeta vacía", donde las cadenas se pueden traducir de forma diferente en función de los roles gramaticales que ejerzan los componentes de las cadenas. Por ejemplo, "vacío" puede ser un verbo o un adjetivo, lo que puede dar lugar a diferentes traducciones en idiomas como italiano o francés.

  6. Evite usar imágenes e iconos que contengan texto en la aplicación. Son costosos de localizar.

  7. Permite un montón de espacio para que la longitud de las cadenas se expanda en la interfaz de usuario. En algunos idiomas, las frases pueden requerir un 50-75 % más de espacio de lo que necesitan en otros idiomas.

  8. Utiliza la System.Resources.ResourceManager clase para recuperar recursos en función de la cultura.

  9. Use Visual Studio para crear cuadros de diálogo de Windows Forms para que se puedan localizar mediante el Editor de recursos de Windows Forms (Winres.exe). No codifiques a mano los cuadros de diálogo de Windows Forms.

  10. Organizar la localización profesional (traducción).

  11. Para obtener una descripción completa de la creación y localización de recursos, consulte Recursos en aplicaciones .NET.

Procedimientos recomendados de globalización para ASP.NET y otras aplicaciones de servidor

Sugerencia

Los procedimientos recomendados siguientes son para aplicaciones de ASP.NET Framework. Para las aplicaciones de ASP.NET Core, consulte Globalización y localización en ASP.NET Core.

  1. Establezca explícitamente las propiedades CurrentUICulture y CurrentCulture en su aplicación. No se base en valores predeterminados.

  2. Tenga en cuenta que ASP.NET aplicaciones son aplicaciones administradas y, por tanto, pueden usar las mismas clases que otras aplicaciones administradas para recuperar, mostrar y manipular información basada en la referencia cultural.

  3. Tenga en cuenta que puede especificar los tres tipos siguientes de codificaciones en ASP.NET:

    • requestEncoding especifica la codificación recibida del explorador del cliente.
    • responseEncoding especifica la codificación que se va a enviar al explorador cliente. En la mayoría de las situaciones, esta codificación debe ser la misma que la especificada para requestEncoding.
    • fileEncoding especifica la codificación predeterminada para .aspx, .asmx y el análisis de archivos .asax .

  4. Especifique los valores de los atributos requestEncoding, responseEncoding, fileEncoding, culture y uiCulture en los tres lugares siguientes en una aplicación de ASP.NET.

    • En la sección de globalización de un archivo Web.config. Este archivo es externo a la aplicación ASP.NET. Para obtener más información, consulte <elemento de globalización>.
    • En una directiva de página. Tenga en cuenta que, cuando una aplicación está en una página, el archivo ya se ha leído. Por lo tanto, es demasiado tarde especificar fileEncoding y requestEncoding. Solo uiCulture, culture y responseEncoding se pueden especificar en una directiva de página.
    • Mediante programación en el código de la aplicación. Esta configuración puede variar por solicitud. Al igual que con una directiva de página, cuando se alcanza el código de la aplicación, es demasiado tarde especificar fileEncoding y requestEncoding. Solo uiCulture, culture y responseEncoding pueden especificarse en el código de la aplicación.

  5. Tenga en cuenta que el valor uiCulture se puede establecer en el idioma de aceptación del explorador.

  6. En el caso de las aplicaciones que se distribuyen, como Azure Container Apps, que permiten actualizaciones sin tiempo de inactividad o similares, debe planear para situaciones en las que pueda haber varias instancias de la aplicación con reglas de formato diferentes u otros datos culturales, siendo las reglas de zona horaria las más relevantes.

    • Si la implementación de la aplicación incluye una base de datos, recuerde que la base de datos tendrá sus propias reglas de globalización. En la mayoría de los casos, debe evitar realizar funciones relacionadas con la globalización en la base de datos.
    • Si la implementación de la aplicación incluye una aplicación cliente o un front-end web mediante recursos de globalización de cliente, suponga que los recursos de cliente difieren de los recursos disponibles para el servidor. Considere la posibilidad de realizar exclusivamente funciones de globalización en el cliente.

Recomendaciones para pruebas sólidas

  1. Para que las dependencias sean más explícitas y las pruebas sean potencialmente más fáciles y se puedan realizar en paralelo, debe considerar la posibilidad de pasar explícitamente la configuración relevante para la referencia cultural, como los parámetros CultureInfo, a los métodos que aplican formato y TimeZoneInfo a los métodos que trabajan con fechas y horas. También debe usar TimeProvider o un tipo similar al recuperar la hora.

  2. Para la mayoría de las pruebas, no debe validar explícitamente la salida exacta de una operación de formato determinada ni el desplazamiento exacto de una zona horaria. El formato y los datos de zona horaria pueden cambiar en cualquier momento y pueden diferir entre dos instancias idénticas de un sistema operativo (y procesos potencialmente diferentes en la misma máquina). Confiar en un valor exacto hace que las pruebas sean frágiles.

    • Por lo general, validar que se recibió alguna salida será suficiente (por ejemplo, cadenas no vacías al dar formato).
    • Para algunos formatos y elementos de datos, se puede validar en su lugar que los datos analicen el valor de entrada (ida y vuelta). Debe tenerse cuidado en los casos en los que se quitan campos (por ejemplo, el año en algunos campos relacionados con la fecha) o el valor se trunca o se redondea (por ejemplo, para la salida de punto flotante).
    • Si tiene requisitos explícitos para validar todas las salidas de formato localizadas, debe considerar la posibilidad de crear y usar una referencia cultural personalizada durante la configuración de prueba. Para la mayoría de los casos simples, esto se puede hacer instanciando un objeto CultureInfo con su constructor new CultureInfo(..) y estableciendo las propiedades DateTimeFormat y NumberFormat. Para casos más complicados, la subclase del tipo permite invalidar propiedades adicionales. Hay posibles ventajas adicionales para esto, como habilitar la pseudolocalización con archivos de recursos.
    • Si tiene requisitos explícitos para validar los resultados de todas las operaciones de fecha y hora, debe considerar la posibilidad de crear y usar una instancia personalizada TimeZoneInfo durante la configuración de prueba. Hay posibles ventajas adicionales para esto, como habilitar pruebas estables de determinados casos perimetrales (por ejemplo, cambios en las reglas de DST).

Consulte también