Usabilidad e internacionalización

Internacionalización, localización, sitio multilingüe… Lo primero es aclarar la terminología porque no siempre se utilizan estos términos correctamente, o al menos de acuerdo a lo que el W3C entiende por cada uno de ellos. Esto puede llevar a equívocos cuando se analiza la documentación sobre internacionalización del W3C o se revisan otras referencias.

Internacionalización y localización

En el documento del W3C “Diferencias entre localización e internacionalización” se definen y acotan estos términos de manera muy clara.

Localización (o "l10n")

Es la adaptación de un producto, una aplicación o el contenido de un documento con el fin de adecuarlo a las necesidades lingüísticas, culturales u otras de un mercado destinatario concreto.

Esta adecuación no es sólo traducirlo a otro idioma sino también tener en cuenta otro tipo de factores que implican adaptarlo en relación con:

diferentes formatos:
- numéricos: por ejemplo separación de miles y decimales con coma o con punto
- de fecha: por ejemplo "02/03/04" puede interpretarse de diferente manera en EEUU, Europa o Japón, como veremos luego; o incluso pueden utilizarse diferentes calendarios
- de hora: formato 12 horas por defecto para EEUU o de 24 horas europeo; pero también puede ser necesario indicar respecto a qué uso horario hace referencia un horario concreto
diferentes monedas y símbolos de las mismas
diferentes medidas de distancia, temperatura, etc.
diferentes alfabetos, dirección de escritura o uso del teclado
diferentes tipos y formatos de tratamientos, nombres y apellidos, direcciones o teléfonos
los algoritmos de comparación y ordenamiento deben adaptarse al idioma, pero a veces también al país, por ejemplo en Islandia los directorios se ordenan por nombre de pila.
diferente significado y percepción de metáforas, símbolos, iconos y colores
los textos y gráficos que contengan referencia a objetos, acciones o ideas que, en una cultura dada, puedan ser objeto de mala interpretación o considerados ofensivos
diferentes exigencias legales
diferentes tamaños estándar de papel (relevante para la impresión)
etc.

Puede suponer incluso la reelaboración exhaustiva de la lógica, el diseño visual o la presentación según cada país y cultura.

Internacionalización (o "l18n")

La internacionalización es el diseño y desarrollo de un producto, una aplicación o el contenido de un documento de modo tal que permita una fácil localización (adaptación del contenido a diferentes idiomas, regiones o culturas según hemos visto anteriormente) sin necesidad de realizar cambios en el código.

Supone la utilización de formatos y protocolos que no establezcan barreras a los diferentes idiomas, sistemas de escritura, códigos y otras convenciones locales, aunque no hayamos llevado a cabo la localización del sitio.

Garantizar la utilización universal de una web en todos los idiomas y culturas implica:

Un modo de diseño y desarrollo que elimine obstáculos a la localización o la distribución internacional: usar Unicode, controlar la concatenación de cadenas, evitar que la programación dependa de valores de cadenas pertenecientes a la interfaz de usuario, etc.
Habilitar características que tal vez no sean usadas hasta el momento de la localización: añadir en la DTD etiquetas para habilitar el texto bidireccional o la identificación de idiomas, hacer la CSS compatible con texto vertical u otras características tipográficas ajenas al alfabeto latino, etc.
Preparar el código para hacer frente a las preferencias locales, regionales, lingüísticas o culturales, como son los de formatos de fecha y hora, calendarios locales, formatos y sistemas de números, ordenamiento y presentación de listas, uso de nombres personales y formas de tratamiento, etc.
Separar del código o contenido los elementos localizables, de modo que puedan cargarse o seleccionarse alternativas localizadas según determinen las preferencias internacionales del usuario.

Más información en Guía breve de internacionalización

Monolingües versus plurilingües

También hay que distinguir los términos “internacional” y “plurilingüe”; el primero es un sitio destinado a un público internacional, y el segundo un sitio que está disponible en más de un idioma. Un sitio web internacional puede ser o no multilingüe, así como un sitio web multilingüe puede ser o no internacional.

Por ejemplo, podemos tener un formulario en el cual se indica un importe en euros, se solicita obligatoriamente dos apellidos y seleccionar de un desplegable una provincia, se pide el DNI, etc., si tal cual se traduce a varios idiomas, da igual que sea multilingüe, no es internacional. En cambio, si se tiene en cuenta a todos los posibles usuarios que pueden utilizar ese formulario, independientemente de su país de origen, será internacional aunque sólo esté disponible en un idioma.

Por tanto, un sitio web internacional presenta información a un público internacional. Y además se puede decidir un enfoque monolingüe o uno plurilingüe.

La decisión depende de los objetivos del portal y su target objetivo.

Es muy interesante al respecto el documento del W3C Sitios web monolingües versus plurilingües donde se indica que el enfoque que se elija dependerá de lo siguiente:

el tipo de material; por ejemplo, ¿es material técnico sencillo o material destinado a motivar o vender?

su público; por ejemplo, ¿es un grupo bien definido que se ajusta a estándares acordados o son lectores en general?

sus medios económicos y recursos; por ejemplo, ¿se puede lograr el enfoque preferido dentro del presupuesto, o es simplemente demasiado complejo o costoso mantener el negocio?

También debería considerar lo siguiente:

los requisitos para acceder a la información; por ejemplo, ¿los usuarios pueden entender sin traducción?

el impacto deseado en el lector; por ejemplo, ¿su intención es motivarlo, persuadirlo o entretenerlo?

lo pertinente o apropiado que sea a la situación de los usuarios; por ejemplo, ¿tiene que considerar diferentes hábitos de compra, precios, requisitos legales u otros diversos contextos sociales del público internacional?

Validador de Internacionalización del W3C

El W3C cuenta con un validador automático W3C Internationalization Checker. Es importante comprender que valida características de internacionalización de la página (no de localización, según la definición del W3C para cada término) asesorando además sobre cómo mejorar el uso del etiquetado en una web multilingüe.

Se puede ver un listado de todos los posibles errores en “Internationalization Checker reports”, algunos por ejemplo son:

Encoding declared only in HTTP header
The html tag has no language attribute
A tag uses a lang attribute without an associated xml:lang attribute (en XHTML)
Incorrect values used for dir attribute
etc.

Pautas para la internacionalización y localización de tu web

W3C

Las mejoras prácticas están resumidas en la tarjeta Internationalization Quick Tips for the Web (PDF) que se desarrolla con más detalle en Consejos rápidos sobre internacionalización para la Web.

Estos 10 consejos son:

Codificación. Utilice Unicode siempre que sea posible para contenidos, bases de datos, etc. Siempre declare la codificación del contenido.
Escapes. Utilice caracteres en lugar de escapes (por ejemplo, á á o á) siempre que sea posible.
Idioma. Declare el idioma de los documentos e indique los cambios de idioma internos.
Presentación vs. contenido. Utilice hojas de estilo para información de presentación. Restrinja el uso de etiquetas para la semántica.
Imágenes, animaciones& ejemplos. Verifique si es posible la traducción y si existe alguna influencia cultural inadecuada.
Formularios. Utilice una codificación adecuada tanto en el formulario como en el servidor. Admita los formatos locales de nombres/direcciones, horas/fechas, etc.
Autoría de texto. Utilice texto simple y conciso. Tenga cuidado al componer oraciones de cadenas múltiples.
Navegación. Incluya en cada página una navegación que pueda verse claramente hacia las páginas o los sitios localizados, utilizando el idioma de llegada.
Texto de derecha a izquierda. Para XHTML, agregue dir="rtl" a la etiqueta html. Utilícela nuevamente sólo para cambiar la dirección de base.
Verifique su trabajo. ¡Realice la validación! Utilice las técnicas, los tutoriales y los artículos que se encuentran en http://www.w3.org/International/

Para conocer a fondo las técnicas y buenas prácticas que recomienda el W3C podemos consultar dos referencias:

Los Artículos, buenas prácticas & tutoriales de la web del Internationalization Core Working Group (W3C Internationalization (l18n) Activity). Se puede acceder al Índice de técnicas y el Índice de temas, que ofrecen un acceso más preciso a la información.
El documento Internationalization Best Practices: Specifying Language in XHTML & HTML Content, del Internationalization Core Working Group (parte del W3C Internationalization Activity) El documento es de 2007 y en él se describen 16 buenas prácticas.

En primer lugar voy a comentar 4 buenas prácticas incluidas en la primera referencia, porque me parecen especialmente importantes. A continuación incluiré las 16 buenas prácticas del documento Internationalization Best Practices: Specifying Language in XHTML & HTML Content

Cómo incluir la selección de idioma

Exponen todos los problemas asociados a que la selección de idioma se realice a través de un desplegable, e indican en qué condiciones puede ser práctico tener o no un enlace a una página de portal global para ello.

Pero si a pesar de todo utilizas un desplegable para seleccionar el idioma te dan una serie de recomendaciones: incluirlo en la esquina superior derecha, traducir cada opción a su idioma, cómo ordenar los valores del desplegable, etc.

Ver: Uso de <select> para enlazar contenido localizado

El tamaño del texto en la traducción

Los textos en inglés ocupan mucho menos que los textos en español. Según esta referencia, en función de la cantidad de caracteres que tenga un texto en inglés, en los idiomas europeos puede llegar a una expansión del 300%.

Por ejemplo “Set the power switch to 0” tiene 26 caracteres. En español “Ponga el interruptor de alimentación de corriente en 0" tiene 55 caracteres, es decir, un 112% más.

¿Están el diseño y la maquetación preparados para que un mismo texto pueda ocupar hasta un 300% más? Cuando un texto está sobre una imagen de fondo (por ejemplo sobre la imagen de fondo de una pestaña) ¿se podrá leer bien, sin cortes o desbordamientos, si se traduce ese texto a otro idioma en el cual ocupe más espacio?

Ver: El tamaño del texto en la traducción

Formatos de fecha

El formato de las fechas puede resultar confuso para aquellos que visitan un sitio web, hablan distintos idiomas y provienen de diferentes regiones.

En EEUU el formato es MM/DD/AA, pero en la mayoría de los países europeos (como España o Inglaterra) es DD/MM/AA, o en Japón es AA/MM/DD. Hay que ser consciente de que una fecha como 02/03/04 en Japón es 4 de marzo de 2002, en Europa 2 de marzo de 2004 y en EEUU 3 de febrero de 2004

Puede que nuestro sitio vaya a ser multilingüe y pensemos que ya se adaptará durante el proceso de localización en función del idioma. Sin embargo, esto no siempre resuelve el problema.

Es decir, si nuestro sitio está en español e inglés, ¿qué formato de fechas ponemos en la versión inglesa? No vamos a tener versiones distintas (para EEUU y para Inglaterra) sólo por los formatos de las fechas.

También puede ser que nuestro sitio esté sólo en un idioma, pero queremos asegurar su internacionalización, que sea lo más comprensible posible por todos los usuarios, independientemente de su idioma o procedencia.

El W3C propone varias alternativas:

usar el formato internacional (ISO 8601): AAAA-MM-DD, pero su desventaja más evidente es que no es amigable para el usuario
usar el formato “2 de abril de 2003”, cuyas principales desventajas es que ocupa más espacio y puede suponer más problemas para hacer ordenaciones cronológicas.
usar el encabezado HTTP Accept-Language, insertando un formato u otro (MM/DD/AA, DD/MM/AA, AA/MM/DD) dinámicamente según la configuración del navegador del usuario.
Sin embargo hay ciertas consideraciones a tener en cuenta, como explican el documento. Por ejemplo, si estás en la versión en inglés y detectas que es un usuario japonés y pones el formato AA/MM/DD, este puede pensar que está viéndolo en el formato inglés MM/DD/AA.

Sobre las preferencias que estableces en el navegador y que serán las que utilizará HTPP Accept-Language, se puede consultar: Setting language preferences in a browser

Por otra parte, si en un formulario se solicita una fecha en un único campo se debe indicar el formato requerido. Si se solicita mediante tres campos, se tiene que indicar qué dato (DD, MM, AAAA) se solicita en cada campo. También es muy útil poder seleccionar la fecha en un calendario.

En el caso de los horarios también habrá que tener en cuenta que deberíamos indicar si estamos utilizando un formato 12 horas o 24 horas, y en base a qué uso horario (si es pertinente).

Ver: Formatos de fechas y Fechas y horarios

Datos que se solicitan en un formulario

Cuando se definen los campos de un formulario, muchas veces no se tiene en cuenta si es un formulario en un sólo idioma pero que pueden rellenar personas de muy diferentes nacionalidades, o si es un formulario que tendrá diferentes versiones para diferentes idiomas.

Pero también hay que tener en cuenta que incluso si el sitio tiene versiones en diferentes idiomas, un mismo idioma es común a muchos países o culturas. O que por ejemplo un francés puede acceder a la versión en inglés si domina este idioma pero no el español (y no hay una versión en francés). O por ejemplo que la versión en español puede estar usándola una persona que vive en España pero es extranjera.

En este apartado se explican cosas como que en Islandia los directorios se ordenan por nombre de pila; que hay países en los que será correcto solicitar dos apellido pero en otros no; que en países como España una persona puede tener nombres compuestos (por ejemplo, María José Quiñones), por tanto diferenciando nombre y apellido en dos campos se podrá procesar automáticamente si debemos llamarla Sra. José o Sra. Quiñones; etc.

¿Qué implica todo esto en el diseño? Que debe ser flexible, y dan recomendaciones concretas como por ejemplo:

La solicitud de primer nombre, inicial de segundo nombre y apellido no es internacional

Ver: Personal names around the world

Como ya he comentado, en el documento Internationalization Best Practices: Specifying Language in XHTML & HTML Content, 2007, se definen asimismo 16 buenas prácticas:

Best Practice 1: Using attributes in the html tag

Always declare the default language for text in the page using attributes on the html tag, unless the document contains content aimed at speakers of more than one language.

Best Practice 2: Using attributes in the html tag for multilingual audiences

Where a document contains content aimed at speakers of more than one language, decide whether you want to declare one language in the html tag, or leave the languages undefined until later.

Best Practice 3: Dividing multilingual documents

Where a document contains content aimed at speakers of more than one language, try to divide the document linguistically at the highest possible level, and declare the appropriate language for each of those divisions.

Best Practice 4: Identifying changes in language within the document

Use the lang and/or xml:lang attributes around text to indicate any changes in language.

Best Practice 5: Choosing between lang and xml:lang

For HTML use the lang attribute only, for XHTML 1.0 served as text/html use the lang and xml:lang attributes, and for XHTML served as XML use the xml:lang attribute only.

Best Practice 6: Choosing between Content-Language and attributes

Use language attributes rather than HTTP or meta elements to declare the default language for text processing.

Best Practice 7: Using the body tag

Do not declare the default language of a document in the body element, use the html element.

Best Practice 8: Handling attribute values and element content in different languages

If the text in attribute values and element content is in different languages, consider using a nested approach

Best Practice 9: Using HTTP or a meta tag to indicate audience

Consider using a Content-Language declaration in the HTTP header or a meta tag to declare metadata about the language(s) of the intended audience of a document.

Best Practice 10: Providing a comma-separated list of languages

Where a document contains content aimed at speakers of more than one language, use Content-Language with a comma-separated list of language tags.

Best Practice 11: Using BCP 47

Follow the guidelines in the IETF's BCP 47 for language attribute values.

Best Practice 12: Deciding on language tag length

Use the shortest possible language tag values.

Best Practice 13: Using Hans and Hant codes

Where possible, use the codes zh-Hans and zh-Hant to refer to Simplified and Traditional Chinese, respectively.

Best Practice 14: Identifying the language of a target document

When pointing to a resource in another language, consider the pros and cons of indicating the language of the target document.

Best Practice 15: Using hreflang with CSS

If you want to indicate that the target document of an a element is in another language, consider the pros and cons of using hreflang with CSS.

Best Practice 16: Using flags to indicate languages

Do not use flag icons to indicate languages.

ISO-9241-151

La comenté en el artículo Estándares formales de usabilidad y su aplicación práctica en una evaluación heurística.

El apartado 10.1 Designing for cultural diversity and multilingual de la ISO-9241-151 recoge 4 pautas:

10.1.1 General

Si se espera que los usuarios de una aplicación web sean culturalmente diversos y/o el uso de diferentes idiomas nativos, la interfaz de usuario de la web debe estar diseñada para tener las características relevantes de los diferentes grupos de usuarios. El apoyo a la diversidad cultural o lingüística se puede lograr proporcionando versiones localizadas de la interfaz de usuario.

10.1.2 Showing relevant location information

Si es relevante para la tarea se debe proporcionar información sobre el contexto geográfico. Por ejemplo, si incluyes un teléfono de contacto, indicas el país o el prefijo de país, si incluyes un horario de atención al usuario queda claro en base a qué uso horario.

10.1.3 Identifying supported languages

Si es una web multilingüe el enlace a los diferentes idiomas debe estar claro y no usar banderas, que siempre identifican países y nunca idiomas. El nombre del idioma debe ser el comúnmente aceptado para él (ISO 639) y en su correspondiente idioma.

También se recomienda, siempre que sea posible, que el cambio de idioma sea sobre la página que se está visualizando (que no se envíe a la home en otro idioma)

Aquí hago yo un inciso. Desde un punto de vista lingüístico, los términos "castellano" y "español" son equivalentes, y da igual utilizar uno u otro término pues ambos son válidos. Sin embargo, a la hora de utilizarlo como enlace al idioma de una web, es mejor usar "español" por las razones que expone el Diccionario Panhispánico de Dudas:

Para designar la lengua común de España y de muchas naciones de América, y que también se habla como propia en otras partes del mundo, son válidos los términos castellano y español. La polémica sobre cuál de estas denominaciones resulta más apropiada está hoy superada.
El término español resulta más recomendable por carecer de ambigüedad, ya que se refiere de modo unívoco a la lengua que hablan hoy más de cuatrocientos millones de personas. Asimismo, es la denominación que se utiliza internacionalmente (Spanish, espagnol, Spanisch, spagnolo, etc.). Aun siendo también sinónimo de español, resulta preferible reservar el término castellano para referirse al dialecto románico nacido en el Reino de Castilla durante la Edad Media, o al dialecto del español que se habla actualmente en esta región. En España, se usa asimismo el nombre castellano cuando se alude a la lengua común del Estado en relación con las otras lenguas cooficiales en sus respectivos territorios autónomos, como el catalán, el gallego o el vasco.

10.1.4 Using appropriate formats, units of measurement or currency

En las interfaces de usuario de uso internacional, la moneda, las unidades de medida, temperaturas, números de teléfono o código postal tienen que estar diseñados de modo que sean comprensibles y usables por una audiencia internacional.

Por ejemplo:

indicar siempre la moneda que corresponda, no dar por supuesto que son euros; o adaptarla según el sitio, o proporcionar el precio en diferentes monedas;
que los campos de formulario para solicitar la dirección den cabida a cualquier tipo de dirección de cualquier país
que las fechas tengan un formato inequívoco para la audiencia internacional, por ejemplo AAAA-MM-DD (ISO 8601). Aunque como hemos dicho antes esto no es muy amigable para el usuario. Además en España habrá usuarios que dudarán si lo que sigue al año es el mes o el día. Así que mejor seguir en este caso la recomendación del W3C: o bien se adapta el formato de la fecha dinámicamente según las preferencias del navegador del usuario (con las consideraciones que comentábamos) o bien se pone en formato texto.

10.1.5 Designing presentation of text in different languages

Para interfaces de usuario multilingües se deben tener en cuenta las características de las diferentes lenguas a la hora de diseñar la presentación y el layout para el texto.

No sólo la diferente longitud de un mismo texto en diferentes idiomas, sino también aspectos como que con los caracteres asiáticos (como el chino) no se visualizan bien con estilos negrita o itálica.

Relación con la accesibilidad

Es importante hacer hincapié siempre en cómo hacer un sitio accesible elimina no sólo barreras de acceso para las personas con discapacidad, sino que también favorece la usabilidad, el acceso desde dispositivos móviles (Accesibilidad y usabilidad móvil: web móvil y app nativa ) o el posicionamiento del sitio (SEO y Accesibilidad. Accesible también para buscadores), pues a menudo son argumentos de apoyo para convencer a los clientes de que deben hacer sitios accesibles.

En este caso, cumplir con las pautas de accesibilidad favorece la internacionalización del sitio.

Algunas de las buenas prácticas que se indican en los documentos que he recomendado coinciden con puntos de verificación de las WCAG 1.0 o criterios de éxito de las WCAG 2.0:

identificar el idioma del documento (punto de verificación 4.3/criterio de conformidad 3.1.1)
indicar los cambios de idioma en el documento (punto de verificación 4.1/criterio de conformidad 3.1.2)
especificar las abreviaciones (punto de verificación 4.2/criterio de conformidad 3.1.4)
identificar las palabras inusuales (criterio de conformidad 3.1.3)
proporcionar un mecanismo para identificar la pronunciación de palabras cuyo significado resulta ambiguo si no se conoce su pronunciación (criterio de conformidad 3.1.6)
separar la estructura y la información de la presentación (punto de verificación 3.3/criterio de conformidad 1.3.1)
marcar diferentes direcciones de lectura (criterio de conformidad 1.3.2)
etc.

Otros enlaces de interés

Es muy recomendable el documento Accessibility and Internationalization (PDF) de Les Kitchen (2009) En él propone ciertas actividades que apoyan la internalización de un sitio y que no hemos nombrado antes:

Anticipate future user groups in advance.
Recruit local expertise.
Prototype and test with target markets.
Use a specialized style guide.
Accumulate information acquired about cultures in organization-wide repositories.
Analyse trade-offs between effort and quality of localization.

Artículos anteriores: