Internacionalización I - Unicode
jueves, 24 de abril de 2008
Joaquín Cuenca
Si habeis conseguido crear una aplicación web (¡felicidades!), lo más probable es que la hayais escrito en inglés o en castellano. No creo que tenga que convencer a nadie de que en ese caso, estais dejando pasar un mercado potencial enorme, ya que hay más gente en el mundo qué no habla inglés o castellano qué la que lo hablan. Para aprovechar el trabajo que teneís hecho y lanzaros a esos nuevos mercados es necesario (aunque tal vez no sea suficiente) traducir vuestra página web a otros idiomas.Read More
Si habeis conseguido crear una aplicación web (¡felicidades!), lo más probable es que la hayais escrito en inglés o en castellano. No creo que tenga que convencer a nadie de que en ese caso, estais dejando pasar un mercado potencial enorme, ya que hay más gente en el mundo qué no habla inglés o castellano qué la que lo hablan. Para aprovechar el trabajo que teneís hecho y lanzaros a esos nuevos mercados es necesario (aunque tal vez no sea suficiente) traducir vuestra página web a otros idiomas.Read More
Joaquín Cuenca
Si habeis conseguido crear una aplicación web (¡felicidades!), lo más probable es que la hayais escrito en inglés o en castellano. No creo que tenga que convencer a nadie de que en ese caso, estais dejando pasar un mercado potencial enorme, ya que hay más gente en el mundo qué no habla inglés o castellano qué la que lo hablan. Para aprovechar el trabajo que teneís hecho y lanzaros a esos nuevos mercados es necesario (aunque tal vez no sea suficiente) traducir vuestra página web a otros idiomas.
El mayor problema con el que os vais a encontrar es la falta de conocimientos sobre internacionalización. Es increíble como muchos programadores, por lo demás perfectamente capacitados, parecen convertirse en Paris Hilton cuando hablan de internacionalización. Eso si llegan a hablar... Vamos a empezar sentando las bases de lo que es un juego de carácteres (charset) y una codificación (encoding). El juego de carácteres es la tabla que traduce de un número a un "carácter" (o para ser más precisos un "codepoint"), y la codificación es el algoritmo que hemos seguido para guardar ese número.
Por ejemplo, el juego de carácteres ISO-8859-1 (también conocido como ISO-Latin-1) es una tabla idéntica a ASCII para números menores de 128, y entre 128 y 255 incluye todos los carácteres necesarios para las lenguas usadas en Europa occidental, excepto por los carácteres Š, š, Ž, ž, Œ, œ, Ÿ, y el €. ISO-8859-15 es idéntico a ISO-8859-1 excepto por la inclusión de estos ocho carácteres. Si usais ISO-Latin-1 y siempre os habeis preguntado por qué había que usar € para conseguir el € en HTML en lugar de poder escribirlo directamente, ya conoceis el motivo. Dado que estos dos charsets, al igual que todos los de la familia ISO-8859 sólo contienen 255 carácteres, el encoding que siempre se usa es el más trivial: guardar cada carácter en un byte.
Sirviendo las páginas siempre en este juego de carácteres podremos tener textos en cualquier idioma de europa occidental. Pero ¿qué pasa con el resto del mundo? podríamos imaginarnos un sistema donde elegimos un juego de carácteres en función del idioma, pero esto no funcionaría si tenemos una página con una mezcla en varios idiomas (muy común si tenemos un sistema de comentarios, y una audiencia internacional) y en general es engorroso e innecesario. Afortunadamente, este problema ha sido resulto por el consorcio Unicode, que se lanzó a la creación de un juego de carácteres que incluyese todos los carácteres usados en el mundo.
Para codificar Unicode se empezó usando dos bytes por carácter. Este encoding se llama UCS-2, y se sigue usando en Windows y en Java. Por algún motivo, en toda la documentación tanto para usuarios como para desarrolladores, a UCS-2 se le llama "Unicode". Dependiendo de la arquitectura en la que estemos, el byte menos significativo de un carácter puede ser el primero, o el segundo, así que tenemos dos variantes de UCS-2, UCS-2LE (LittleEndian) y UCS-2BE (BigEndian). Para distinguir qué variante se está usando se le añade al principio del texto el carácter 0xFEFF "ZERO WIDTH NO-BREAK SPACE" (también conocido como el "BOM", Byte Order Marker). Así, si nos encontramos con un carácter BOM sabemos que estamos leyendo UTF-16 en el orden correcto. Si nos encontramos con un BOM reflejado (0xFFFE) sabemos que estamos leyendo al revés, ya que 0xFFFE no existe en Unicode.
Cuando UCS-2 se quedó corto para almacenar todos los carácteres del mundo y hubo que ir más allá de 0xFFFF, se añadió una extensión y se le llamó UTF-16, donde se usan dos carácteres especiales (llamados surrogates pair) para indicar que los bytes siguientes están fuera del plano básico. Se pierde así el único interés que tenía UTF-16, y es que se podía saltar directamente al carácter en la posición "n", ya que se conocía el tamaño de cada carácter (2 bytes). En realidad UCS-2 nunca tuvo esta cualidad, ya que ciertos carácteres en Unicode no son tales (por eso su nombre técnico es¨"codepoint"). Algunos codepoints son sólo un indicador que dice que hay que modificar el carácter que le sigue, por ejemplo añadiéndole un acento. ¿Y por qué no podían codificar cada carácter con un acento por separado, sin tener que recurrir a modificadores? Empezaron así, por eso tenemos un carácter independiente para "á", pero este método dejó de funcionar cuando se llegó al vietnamita (echadle un vistazo a un texto en vietnamita y vereis en seguida el motivo...).
También se creó otra codificación alternativa, UTF-32 (o UCS-4), qué consistía en guardar cada codepoint con 4 bytes. En realidad 3 bastan, pero en aras de mantener todos los carácteres alineados para arquitecturas de 4 bytes se añade uno extra (ya que estamos desperdiciando espacio...). Este es el motivo por el que en linux wchar_t mide 4 bytes, mientras que en Windows mide 2.
Estos dos encodings tienen en común que para los carácteres occidentales incluyen un byte con valor 0. Pero en una cadena C, el byte con valor 0 tiene el significado especial de ser el final de la cadena de texto. Todos los programas que usan C y leen texto tienen que cambiarse, ya que strlen, strcpy, etc. ya no funcionan con estos textos.
Así estaban las cosas cuando Ken Thompson y Rob Pike inventaron un nuevo encoding de tamaño variable llamado UTF-8. UTF-8 es idéntico a ASCII para todos los carácteres inferiores a 128, y usa uno o varios bytes extra (hasta un máximo de 4) cuando tiene que almacenar un número superior a 128. Cualquier texto ASCII en inglés es automáticamente un texto UTF-8 válido. Los textos europeos son en torno a un 2% más grandes que usando ISO-8859-15, ya que sólo los carácteres acentuados aumentan de tamaño. Los únicos que realmente salen perdiendo son aquellos que tenían un alfabeto pequeño (griego, ruso, ...) sin nada en común con el inglés, ya que antes podían codificar cada carácter con un 1 byte y ahora necesitan más. UTF-8 no usa ningún byte 0 en su codificación, y funciones como strcpy funcionan con textos UTF-8.
Mi recomendación es usar UTF-8 tanto en la base de datos como en la interfaz web. Algunos consejos prácticos:
Si guardais un texto en Windows como UTF-8, teneis muchas posibilidades de que el editor añada un "BOM" (también llamado "signature"). El BOM era útil para UTF-16, pero para UTF-8 es totalmente irrelevante, ya que en UTF-8 los carácteres se leen en un array de bytes, y el orden de la arquitectura no cambia nada (no existe un UTF-8 LE o UTF-8 BE). Pero en Windows lo siguen escribiendo para poder distinguir texto codificado en UTF-8 del codificado con otro encoding. Cuidad de usar un editor que os permita guardar en UTF-8 sin BOM, o vereis como vuestras páginas escriben tres bytes de más al principio de cada página web (el carácter BOM escrito en UTF-8 es EF BB BF). Si no la función headers en PHP os da un error porque ya habeis escrito "algo" en la página, y no sabeis lo que es, comprobad si el BOM está ahí y quitadlo.
Codificar vuestros textos en UTF-8 es el primer paso, pequeño pero significativo, para la internacionalización de vuestra página. En el próximo artículo veremos un ejemplo práctico de como traducir una página web.
Por último, es interesante saber que no basta con conocer el carácter que se le quiere mostrar al usuario para saber que grafía (en inglés, el glyph) hay que mostrar en pantalla.
Algunos idiomas como el árabe son contextuales, el mismo carácter puede tener 4 grafías distintas según esté solo, empiece la palabra, esté en medio, o la termine. Otros idiomas comparten carácteres, pero cambian ligeramente (o radicalmente) su grafía. El ejemplo más conocido es el de los scripts hanzi (Chino), kanji (Japonés) y hanja (Koreano). Estos scripts tienen un origen común, pero con el tiempo la forma de representar esos carácteres ha ido evolucionando. Así, si tenemos que mezclar en un mismo documento un carácter kanji Japonés con su equivalente en Chino tradicional, debemos indicar de alguna forma que una parte del texto está en Japones y otra en Chino tradicional. El mismo problema tiene el serbio, que se puede escribir en latín, o en cirílico, pero con la particularidad de que en cirílico algunas grafías cambian con respecto al cirílico ruso (ver este artículo sobre tipografía para más información). A pesar de que en HTML podemos indicar el language del documento, o de trozos de texto, usando el atributo "lang".
Ningún navegador cambia las grafías en función del idioma elegido, así que podeis considerar el párrafo anterior como puramente teórico, pero aún así es interesante poner correctamente el atributo "lang" ya que la pronunciación al igual que las grafías dependen del idioma (¡y de forma muchísimo más marcada!) y para personas invidentes es importante que su lector sepa con que voz debe de leer el texto.
Por cierto, Rob Pike trabaja en Google. Si quieres trabajar en un ambiente genial, con brillantes compañeros, envía tu CV a Google.
Si habeis conseguido crear una aplicación web (¡felicidades!), lo más probable es que la hayais escrito en inglés o en castellano. No creo que tenga que convencer a nadie de que en ese caso, estais dejando pasar un mercado potencial enorme, ya que hay más gente en el mundo qué no habla inglés o castellano qué la que lo hablan. Para aprovechar el trabajo que teneís hecho y lanzaros a esos nuevos mercados es necesario (aunque tal vez no sea suficiente) traducir vuestra página web a otros idiomas.
El mayor problema con el que os vais a encontrar es la falta de conocimientos sobre internacionalización. Es increíble como muchos programadores, por lo demás perfectamente capacitados, parecen convertirse en Paris Hilton cuando hablan de internacionalización. Eso si llegan a hablar... Vamos a empezar sentando las bases de lo que es un juego de carácteres (charset) y una codificación (encoding). El juego de carácteres es la tabla que traduce de un número a un "carácter" (o para ser más precisos un "codepoint"), y la codificación es el algoritmo que hemos seguido para guardar ese número.
Por ejemplo, el juego de carácteres ISO-8859-1 (también conocido como ISO-Latin-1) es una tabla idéntica a ASCII para números menores de 128, y entre 128 y 255 incluye todos los carácteres necesarios para las lenguas usadas en Europa occidental, excepto por los carácteres Š, š, Ž, ž, Œ, œ, Ÿ, y el €. ISO-8859-15 es idéntico a ISO-8859-1 excepto por la inclusión de estos ocho carácteres. Si usais ISO-Latin-1 y siempre os habeis preguntado por qué había que usar € para conseguir el € en HTML en lugar de poder escribirlo directamente, ya conoceis el motivo. Dado que estos dos charsets, al igual que todos los de la familia ISO-8859 sólo contienen 255 carácteres, el encoding que siempre se usa es el más trivial: guardar cada carácter en un byte.
Sirviendo las páginas siempre en este juego de carácteres podremos tener textos en cualquier idioma de europa occidental. Pero ¿qué pasa con el resto del mundo? podríamos imaginarnos un sistema donde elegimos un juego de carácteres en función del idioma, pero esto no funcionaría si tenemos una página con una mezcla en varios idiomas (muy común si tenemos un sistema de comentarios, y una audiencia internacional) y en general es engorroso e innecesario. Afortunadamente, este problema ha sido resulto por el consorcio Unicode, que se lanzó a la creación de un juego de carácteres que incluyese todos los carácteres usados en el mundo.
Para codificar Unicode se empezó usando dos bytes por carácter. Este encoding se llama UCS-2, y se sigue usando en Windows y en Java. Por algún motivo, en toda la documentación tanto para usuarios como para desarrolladores, a UCS-2 se le llama "Unicode". Dependiendo de la arquitectura en la que estemos, el byte menos significativo de un carácter puede ser el primero, o el segundo, así que tenemos dos variantes de UCS-2, UCS-2LE (LittleEndian) y UCS-2BE (BigEndian). Para distinguir qué variante se está usando se le añade al principio del texto el carácter 0xFEFF "ZERO WIDTH NO-BREAK SPACE" (también conocido como el "BOM", Byte Order Marker). Así, si nos encontramos con un carácter BOM sabemos que estamos leyendo UTF-16 en el orden correcto. Si nos encontramos con un BOM reflejado (0xFFFE) sabemos que estamos leyendo al revés, ya que 0xFFFE no existe en Unicode.
Cuando UCS-2 se quedó corto para almacenar todos los carácteres del mundo y hubo que ir más allá de 0xFFFF, se añadió una extensión y se le llamó UTF-16, donde se usan dos carácteres especiales (llamados surrogates pair) para indicar que los bytes siguientes están fuera del plano básico. Se pierde así el único interés que tenía UTF-16, y es que se podía saltar directamente al carácter en la posición "n", ya que se conocía el tamaño de cada carácter (2 bytes). En realidad UCS-2 nunca tuvo esta cualidad, ya que ciertos carácteres en Unicode no son tales (por eso su nombre técnico es¨"codepoint"). Algunos codepoints son sólo un indicador que dice que hay que modificar el carácter que le sigue, por ejemplo añadiéndole un acento. ¿Y por qué no podían codificar cada carácter con un acento por separado, sin tener que recurrir a modificadores? Empezaron así, por eso tenemos un carácter independiente para "á", pero este método dejó de funcionar cuando se llegó al vietnamita (echadle un vistazo a un texto en vietnamita y vereis en seguida el motivo...).
También se creó otra codificación alternativa, UTF-32 (o UCS-4), qué consistía en guardar cada codepoint con 4 bytes. En realidad 3 bastan, pero en aras de mantener todos los carácteres alineados para arquitecturas de 4 bytes se añade uno extra (ya que estamos desperdiciando espacio...). Este es el motivo por el que en linux wchar_t mide 4 bytes, mientras que en Windows mide 2.
Estos dos encodings tienen en común que para los carácteres occidentales incluyen un byte con valor 0. Pero en una cadena C, el byte con valor 0 tiene el significado especial de ser el final de la cadena de texto. Todos los programas que usan C y leen texto tienen que cambiarse, ya que strlen, strcpy, etc. ya no funcionan con estos textos.
Así estaban las cosas cuando Ken Thompson y Rob Pike inventaron un nuevo encoding de tamaño variable llamado UTF-8. UTF-8 es idéntico a ASCII para todos los carácteres inferiores a 128, y usa uno o varios bytes extra (hasta un máximo de 4) cuando tiene que almacenar un número superior a 128. Cualquier texto ASCII en inglés es automáticamente un texto UTF-8 válido. Los textos europeos son en torno a un 2% más grandes que usando ISO-8859-15, ya que sólo los carácteres acentuados aumentan de tamaño. Los únicos que realmente salen perdiendo son aquellos que tenían un alfabeto pequeño (griego, ruso, ...) sin nada en común con el inglés, ya que antes podían codificar cada carácter con un 1 byte y ahora necesitan más. UTF-8 no usa ningún byte 0 en su codificación, y funciones como strcpy funcionan con textos UTF-8.
Mi recomendación es usar UTF-8 tanto en la base de datos como en la interfaz web. Algunos consejos prácticos:
Si guardais un texto en Windows como UTF-8, teneis muchas posibilidades de que el editor añada un "BOM" (también llamado "signature"). El BOM era útil para UTF-16, pero para UTF-8 es totalmente irrelevante, ya que en UTF-8 los carácteres se leen en un array de bytes, y el orden de la arquitectura no cambia nada (no existe un UTF-8 LE o UTF-8 BE). Pero en Windows lo siguen escribiendo para poder distinguir texto codificado en UTF-8 del codificado con otro encoding. Cuidad de usar un editor que os permita guardar en UTF-8 sin BOM, o vereis como vuestras páginas escriben tres bytes de más al principio de cada página web (el carácter BOM escrito en UTF-8 es EF BB BF). Si no la función headers en PHP os da un error porque ya habeis escrito "algo" en la página, y no sabeis lo que es, comprobad si el BOM está ahí y quitadlo.
Codificar vuestros textos en UTF-8 es el primer paso, pequeño pero significativo, para la internacionalización de vuestra página. En el próximo artículo veremos un ejemplo práctico de como traducir una página web.
Por último, es interesante saber que no basta con conocer el carácter que se le quiere mostrar al usuario para saber que grafía (en inglés, el glyph) hay que mostrar en pantalla.
Algunos idiomas como el árabe son contextuales, el mismo carácter puede tener 4 grafías distintas según esté solo, empiece la palabra, esté en medio, o la termine. Otros idiomas comparten carácteres, pero cambian ligeramente (o radicalmente) su grafía. El ejemplo más conocido es el de los scripts hanzi (Chino), kanji (Japonés) y hanja (Koreano). Estos scripts tienen un origen común, pero con el tiempo la forma de representar esos carácteres ha ido evolucionando. Así, si tenemos que mezclar en un mismo documento un carácter kanji Japonés con su equivalente en Chino tradicional, debemos indicar de alguna forma que una parte del texto está en Japones y otra en Chino tradicional. El mismo problema tiene el serbio, que se puede escribir en latín, o en cirílico, pero con la particularidad de que en cirílico algunas grafías cambian con respecto al cirílico ruso (ver este artículo sobre tipografía para más información). A pesar de que en HTML podemos indicar el language del documento, o de trozos de texto, usando el atributo "lang".
Ningún navegador cambia las grafías en función del idioma elegido, así que podeis considerar el párrafo anterior como puramente teórico, pero aún así es interesante poner correctamente el atributo "lang" ya que la pronunciación al igual que las grafías dependen del idioma (¡y de forma muchísimo más marcada!) y para personas invidentes es importante que su lector sepa con que voz debe de leer el texto.
Por cierto, Rob Pike trabaja en Google. Si quieres trabajar en un ambiente genial, con brillantes compañeros, envía tu CV a Google.
