Localización

  • Artículo

En esta guía se presentan los conceptos de internacionalización y localización y vínculos a instrucciones sobre cómo generar aplicaciones móviles de Xamarin con esos conceptos.

Si quiere ir directamente a los detalles técnicos de la localización de aplicaciones de Xamarin, comience con uno de estos artículos de procedimientos específicos de la plataforma:

i18n y L10n

La internacionalización es el proceso de hacer que el código sea capaz de mostrar diferentes idiomas y adaptar su presentación para diferentes configuraciones regionales (como el formato de número y fecha). Este proceso también se conoce como globalización.

La localización es el paso siguiente: crear recursos (como cadenas e imágenes) para cada idioma y agruparlos con la aplicación de internacionalización.

"Internacionalización" a menudo se abrevia como "i18n", por las 18 letras que hay entre la "i" y la "n". De forma similar, "localización" se abrevia como "L10n", por las 10 letras que hay entre la "l" y la "n.

Información general

En este documento se presentan los conceptos asociados a la internacionalización y la localización, y cómo se aplican al desarrollo de aplicaciones móviles en general. Al diseñar y crear una aplicación, entre las cosas que previamente podría haber codificado, pero que deben parametrizarse para la localización, se incluyen las siguientes:

  • Diseños de pantalla y texto
  • Iconos, gráficos y colores
  • Archivos de vídeo y sonido
  • Texto dinámico y formato de texto (como números, monedas y fechas)
  • Cambios de diseño para idiomas de derecha a izquierda (RTL)
  • Ordenación de datos

Independientemente de las plataformas móviles a las que se dirija su aplicación, estos consejos le ayudarán a crear una aplicación localizada de alta calidad.

Consideraciones de diseño

Diseñar una aplicación para que sea posible localizar su contenido se denomina "internacionalización". Realizar una internacionalización correcta es algo más que permitir que se carguen diferentes cadenas de lenguaje en tiempo de ejecución: una aplicación bien diseñada debe permitir que todos los recursos se cambien en función del idioma y la configuración regional (incluidas las imágenes, los sonidos y los vídeos) y que se pueda adaptar el formato y el diseño para hacer frente a cadenas de diferentes tamaños.

En esta sección se describen algunas consideraciones de diseño que se deben tener en cuenta al compilar una aplicación internacionalizada.

Diseños y longitud de cadena

Las cadenas en chino y japonés pueden ser muy cortas: a veces uno o dos caracteres pueden ser lo suficientemente significativos para una etiqueta de campo de entrada.

Las cadenas en alemán, por ejemplo, pueden ser muy largas; a veces una palabra relativamente corta en inglés acaba siendo muy larga en otros idiomas y queda truncada o cambia inesperadamente el diseño.

Compare las longitudes de cadena de algunos elementos de la pantalla principal en iOS para inglés, alemán y japonés:

German vs Japanese string length

Observe que Settings (Configuración) en inglés (8 caracteres) requiere 13 caracteres para la traducción alemana, pero solo 2 caracteres para el japonés.

Es difícil trabajar con diseños en los que la etiqueta de visualización y el campo de entrada están uno al lado del otro cuando la longitud de la etiqueta puede variar mucho. A menudo, un diseño en el que la etiqueta se muestra encima de un campo es más fácil de localizar porque el ancho completo de la pantalla está disponible para la etiqueta y la entrada.

Como regla general, si está creando diseños fijos (especialmente elementos uno al lado del otro), permita al menos un 50 % más de ancho que el que requieren las cadenas en inglés para etiquetas y texto. Esta medida no resolverá todos los problemas, pero proporcionará un margen que funcionará en muchos casos.

Validación de la entrada

Tenga cuidado con las suposiciones al escribir reglas de validación. Podría parecer válido requerir que la entrada de un campo de texto "exija" al menos tres caracteres en inglés, ya que una sola letra rara vez tiene significado. Sin embargo, en chino y japonés un solo carácter puede ser una entrada válida y el mensaje de validación "Se requieren al menos 3 caracteres" no tiene sentido para esos idiomas.

Otras tareas aparentemente simples, como validar una dirección de correo electrónico o la URL de un sitio web, se vuelven más complicadas cuando los caracteres no se limitan al subconjunto ASCII.

Escriba las reglas de validación teniendo en cuenta la internacionalización: elija las reglas menos restrictivas o escriba la lógica para que funcione de forma diferente para cada idioma.

Imágenes y color

No todas las imágenes deben cambiar en función de la elección de idioma de un usuario. Muchos iconos o fotos serán adecuados para todos los usuarios, independientemente del idioma que hablen. Sin embargo, tiene sentido localizar algunos recursos, como los siguientes:

  • Imágenes que muestran personas o ubicaciones específicas: la aplicación puede parecer más relevante para los usuarios si muestra personas o ubicaciones locales.
  • Iconos: parte de la iconografía puede ser específica de una cultura y puedes hacer que tu aplicación sea más fácil de usar localizando las imágenes para reflejar la comprensión local.
  • Colores: algunas culturas entienden los colores de manera diferente: el rojo puede significar advertencia en una región, pero buena suerte en otra. Consulte con hablantes nativos al diseñar su aplicación para determinar si debería crear un mecanismo para localizar los colores.

Vídeos y sonido

Los vídeos y el sonido presentan desafíos especiales a la hora de localizar una aplicación, porque si bien es relativamente fácil traducir cadenas, grabar varias pistas de voz en off o clips de vídeo puede resultar costoso y difícil.

Varias copias de archivos de vídeo y sonido también pueden aumentar significativamente el tamaño de su aplicación (especialmente si está localizando a una gran cantidad de idiomas o tiene muchos archivos multimedia). Es posible que considere la posibilidad de descargar solo los recursos de idioma necesarios después de que el usuario haya instalado la aplicación, pero esto también podría dar lugar a una mala experiencia de usuario en redes lentas.

A menudo, existen varias formas de resolver los problemas de localización; lo más importante es considerarlos desde el principio y asegurarse de que su aplicación esté diseñada para solucionarlos.

Fechas, horas, números y monedas

Si está utilizando funciones de formato .NET, recuerde especificar la cultura para que los separadores decimales se analicen correctamente y evitar que se generen excepciones de conversión. Por ejemplo, tanto "1.99" como "1,99" son representaciones decimales válidas en función de la configuración regional.

Cuando los datos provienen de una fuente conocida (es decir, de su propio código o de un servicio web que usted controla), puede codificar un identificador cultural que coincida con el formato, como InvariantCulture, que funcionará para el formato estándar del idioma inglés.

double.Parse("1,999.99", CultureInfo.InvariantCulture);

Si el usuario de la aplicación es quien introduce los datos, analícelos usando una instancia de CultureInfo que refleje su ubicación:

double.Parse("1 999,99", CultureInfo.CreateSpecificCulture("fr-FR"));

Consulte los artículos de MSDN Análisis de cadenas numéricas y Análisis de cadenas de fecha y hora para obtener información adicional.

Idiomas de derecha a izquierda (RTL)

Algunos idiomas, como el árabe, el hebreo y el urdu (por ejemplo), se leen de derecha a izquierda. Las aplicaciones que admiten estos idiomas deben utilizar diseños de pantalla que se adapten a los lectores de derecha a izquierda, por ejemplo:

  • El texto debe estar alineado a la derecha.
  • Las etiquetas deben aparecer a la derecha de los campos de entrada.
  • La colocación predeterminada del botón se invierte generalmente.
  • El deslizamiento y la animación de navegación jerárquica (y otras metáforas y animaciones de navegación) que utilizan la dirección para el contexto también deben invertirse.

Tanto iOS como Android admiten diseños de derecha a izquierda y representación de fuentes, con características integradas que ayudan a realizar los ajustes anteriores. Xamarin.Forms no admite actualmente la representación RTL de forma automática.

Ordenar

Los distintos idiomas definen el criterio de ordenación de sus alfabetos de forma diferente, incluso cuando usan el mismo juego de caracteres.

Vea Detalles de la comparación de cadenas en Procedimientos recomendados para el uso de cadenas en .NET Framework para consultar un ejemplo en el que el idioma (CultureInfo) afecta al orden de clasificación.

Es poco probable que las capacidades de base de datos integradas en las plataformas móviles admitan el orden de clasificación específico del idioma, por lo que es posible que deba implementar código adicional en su lógica empresarial.

Búsqueda de texto

Asegúrese de escribir y probar el algoritmo de búsqueda teniendo en cuenta varios idiomas. Entre las cosas que se deben tener en cuenta, se incluyen las siguientes:

  • Autocompletado: si ha creado una función de autocompletado, asegúrese de que genera sugerencias relevantes para el idioma del usuario.
  • Consulta coincidente con los datos: ¿las consultas de búsqueda introducidas en un idioma específico se ejecutarán solo con el contenido escrito en ese idioma o con todo el contenido de su aplicación?
  • Derivación: si su búsqueda está diseñada para buscar palabras similares, raíces de palabras y otras optimizaciones de búsqueda, ¿están dichas optimizaciones diseñadas para todos los idiomas que admite?
  • Ordenación: asegúrese de que los resultados se ordenan correctamente (consulte la sección anterior).

Datos de orígenes externos

Muchas aplicaciones descargan datos de orígenes externos, desde Twitter y canales RSS hasta del clima, las noticias o los precios de las acciones. Al mostrarle esto a un usuario, debe considerar la posibilidad de si le estará mostrando una pantalla con información irrelevante o ilegible.

Hay algunas estrategias que puede usar para probar y asegurarse de que la aplicación muestre datos relevantes para el usuario:

  • Orígenes diferentes: la aplicación puede descargar los datos de un origen diferente en función del idioma o la configuración regional del usuario. Las noticias locales, el tiempo y los precios de las acciones pueden tener más sentido que algo descargado de una fuente de Norteamérica.
  • Visualización localizada: si muestra Twitter o una fuente de fotografías, deberá mostrar los metadatos (como el tiempo transcurrido) en su propio idioma, incluso aunque el contenido en sí permanezca en el idioma original.
  • Traducción: puede crear una opción de traducción en su aplicación para realizar una traducción automática de los datos entrantes. Esto podría ser automático o a discreción del usuario; simplemente asegúrese de notificárselo, ya que las traducciones automáticas nunca son perfectas.

Esto también podría afectar los enlaces externos a pistas de audio o vídeos: al diseñar su aplicación, asegúrese de planificar con anticipación la obtención de contenido traducido o asegúrese de que la interfaz de usuario informe adecuadamente a los usuarios cuando el contenido no se presentará en su idioma.

No traduzca más de lo necesario

Es posible que algunas cadenas de su aplicación no necesiten traducción o que simplemente necesiten un mínimo de atención especial por parte del traductor. Entre otros ejemplos, se pueden incluir:

  • Direcciones URL: si enumera una dirección URL, es posible que sea necesario adaptarla a cada idioma o no. Por ejemplo, facebook.com no requiere traducción, detecta automáticamente el idioma en el sitio principal. Otros sitios tienen contenido específico de la configuración regional y es posible que quiera ofrecer una dirección URL diferente, como yahoo.com frente a yahoo.fr o yahoo.it.
  • Números de teléfono: especialmente aquellos con diferentes códigos de país o números para los autores de llamadas que hablan un idioma determinado.
  • Detalles de contacto: las direcciones y otra información pueden variar según el idioma o la ubicación.
  • Marcas comerciales y nombres de productos: algunas cadenas no necesitan traducirse porque siempre están escritas en el mismo idioma.

Por último, asegúrese de incluir instrucciones detalladas para el traductor si ciertas cadenas requieren un tratamiento especial.

Texto con formato

Por lo general, esto no supone un problema con las aplicaciones móviles porque las cadenas generalmente no tienen un formato enriquecido. Sin embargo, si su aplicación requiere texto enriquecido (como formato en negrita o cursiva), asegúrese de que el traductor sepa cómo aplicar el formato, que sus archivos de cadenas lo almacenen correctamente y que el formato esté aplicado correctamente antes de mostrarlo al usuario (es decir, no deje que los códigos de formato se muestren al usuario accidentalmente).

Sugerencias de traducción

La traducción de las cadenas que utiliza una aplicación se considera parte del proceso de localización. Normalmente, esta tarea se externalizará a un servicio de traducción y la realizará el personal multilingüe que es posible que no conozca su aplicación o su negocio.

Los siguientes consejos le ayudarán a producir cadenas que sean más fáciles de traducir con precisión y, por tanto, mejorarán la calidad de sus aplicaciones localizadas.

Localice cadenas completas, no palabras

A veces, los desarrolladores adoptan el enfoque de intentar especificar palabras individuales o "fragmentos" de oraciones para poder reutilizarlos en toda la aplicación. Por ejemplo, para el texto "Tiene 5 mensajes". podrían especificar las siguientes cadenas para la traducción

Incorrecto:

"You have"
"no"
"message"
"messages"

y, a continuación, intentar crear la frase correcta sobre la marcha en el código mediante la concatenación de cadenas:

Incorrecto:

"You have" + " " + numMsgs + " " + "messages"
"You have" + " no " + "messages"

Esto se desaconseja porque no funcionará necesariamente para todos los idiomas y será difícil que el traductor comprenda el contexto de cada segmento corto. También conduce a la reutilización de cadenas traducidas, lo que puede causar problemas más adelante si se usan en diferentes contextos y luego se actualizan.

Permita la reordenación de parámetros

Algunos lenguajes de programación requieren sintaxis adicional para especificar el orden de los parámetros en una cadena; sin embargo, .NET ya admite el concepto de marcadores de posición numerados,

Correcto:

"a {0} b {1} cde {3}"

por lo que podría traducirse de la siguiente manera (en la que se cambia la posición y el orden de los marcadores de posición)

"{2} {3} f g h {0}"

y los tokens se ordenarán según lo previsto por el traductor. Asegúrese de incluir una explicación de lo que contiene cada marcador de posición al enviar la cadena a un traductor.

Use varias cadenas para la cardinalidad

Evite cadenas como "You have {0} message/s.". Use cadenas específicas para cada estado para proporcionar una mejor experiencia de usuario:

Correcto:

"You have no messages."
"You have 1 message."
"You have 2 messages."
"You have {0} messages."

Tendrá que escribir código en la aplicación para evaluar el número que se muestra y elegir la cadena adecuada. Algunas plataformas (incluidas iOS y Android) tienen características integradas para elegir automáticamente la mejor cadena en plural en función de las preferencias del idioma o la configuración regional actuales.

Permita la variación de género

Los idiomas que provienen del latín a veces usan palabras diferentes en función del género del sujeto. Si su aplicación tiene marcadores de género, debe permitir que las cadenas traducidas lo reflejen.

También existe el caso más obvio, incluso en inglés, en el que las cadenas hacen referencia a una persona o usuario específicos de la aplicación. Por ejemplo, algunos sitios muestran mensajes como este: "Bob commented on his post", así que necesitarán cadenas para un género masculino, femenino, no binario y desconocido:

Correcto:

"{0} commented on his post"
"{0} commented on her post"
"{0} commented on their post"

No reutilice las cadenas

O más concretamente, no reutilice las cadenas simplemente porque son similares cuando la propia cadena tiene un propósito o significado diferente.

Por ejemplo, imagine que tiene un interruptor de encendido y apagado en su aplicación y el control del interruptor necesita que se localice el texto "Encendido" y "Apagado". También se muestra el valor de esa configuración en otra parte de la aplicación en una etiqueta de texto. Deberá usar cadenas diferentes para la pantalla del interruptor y el estado de este (incluso aunque sean la misma cadena en el idioma predeterminado), por ejemplo:

  • "On" en el propio interruptor
  • "Off" en el propio interruptor
  • "On" en una etiqueta
  • "Off" en una etiqueta

Esto proporciona la máxima flexibilidad para el traductor:

  • Por motivos de diseño, quizás el propio interruptor usa "on" y "off" en minúsculas, pero la etiqueta de pantalla se muestra con una mayúscula inicial: "On" y "Off".
  • Es posible que en algunos idiomas sea necesario abreviar el valor del interruptor para que quepa en el control de la interfaz de usuario, mientras que la palabra completa (traducida) puede aparecer en la etiqueta.
  • Como alternativa, para algunos idiomas, la representación del interruptor podría ser "I" y "O", ya que son símbolos que se suelen conocer en todas las culturas, pero es posible que quiera que en la etiqueta se muestre la palabra completa.

Servicios de traducción

Traducción automática

Para crear características de traducción en la aplicación, considere la posibilidad de usar Azure Translator Text API.

Con fines de prueba, puede usar una de las muchas herramientas de traducción que hay en línea para incluir texto localizado en la aplicación durante el desarrollo:

Hay muchas otros disponibles. Por lo general, la calidad de la traducción automática no se considera lo suficientemente buena como para publicar una aplicación sin que los traductores profesionales o los hablantes nativos la hayan revisado y probado primero.

Traducción profesional

También hay servicios de traducción profesionales que distribuirán sus cadenas entre sus propios traductores, por lo que tendrá el contenido traducido pagando una tarifa.

Uno de los servicios más conocidos es LionBridge. La mayoría de los servicios profesionales admiten todos los tipos de archivo comunes, como cadenas, XML, RESX y POT/PO.

Resumen

En este artículo se han introducido algunos de los conceptos que debería conocer antes de internacionalizar la aplicación y, a continuación, localizar los recursos, y también se ha explicado cómo cambiar las preferencias de idioma para cada plataforma.

Estos conceptos se pueden aplicar a las distintas técnicas de internacionalización multiplataforma y específicas de la plataforma que son posibles con Xamarin.

Continúe leyendo los detalles técnicos de la plataforma que le interesan: