¿Por qué usar Unicode si su programa es solo inglés?

Question

He leído Joel's article, y miré a través de SO, y parece que la única razón para cambiar de ASCII a Unicode es la internacionalización. La compañía para la que trabajo, como política, solo lanzará software en inglés, aunque tengamos clientes en todo el mundo. Dado que todos nuestros clientes son científicos, tienen suficiente inglés funcional para usar nuestro software como un hablante no nativo. O eso dice la lógica. Debido a esta política, no es necesario cambiar a Unicode para admitir otros idiomas.

Sin embargo, estoy comenzando un nuevo proyecto y quería utilizar Unicode (porque eso es lo que se supone que debe hacer un programador responsable, ¿no?). Para hacerlo, deberíamos comenzar a convertir todas las bibliotecas que hemos escrito en Unicode. Esto no es tarea fácil.

Si la internacionalización de los programas no se considera una razón válida, ¿cómo justificar todo el tiempo dedicado a recodificar bibliotecas y programas para cambiar a Unicode?

Answer 1

Esto obviamente depende de lo que tu aplicación realmente hace, pero el hecho de que solo tengas una versión en inglés de ninguna manera significa que la internacionalización no sea un problema.

¿Qué ocurre si deseo almacenar un nombre de cliente que utiliza caracteres que no sean inglés? ¿O el nombre de un lugar en otro país?

Como una ventaja adicional (dado que dices que estás apuntando a científicos) es que todo tipo de símbolos científicos y notificaciones son compatibles como parte de Unicode.

En última instancia, me resulta mucho más fácil ser coherente. Unicode se comporta igual sin importar en qué computadora ejecuta la aplicación. No unicode significa que utiliza de forma predeterminada un conjunto de caracteres o una página de códigos dependientes de la configuración regional, por lo que el texto que se ve bien en su computadora puede estar lleno de caracteres basura en el de otra persona.

Aparte de eso, probablemente no necesite traducir todas sus bibliotecas a Unicode de una sola vez. Escriba envoltorios según sea necesario para convertir entre Unicode y cualquier codificación que use de otra manera.

Si usa UTF-8 para su texto Unicode, incluso tiene la capacidad de leer cadenas simples ASCII, lo que debería ahorrarle algunos dolores de cabeza de conversión.

Answer 2

Dicen que siempre lo pondrán en inglés ahora, pero admite que tiene clientes en todo el mundo. Un cliente entra y dice que la internacionalización es un factor decisivo, ¿realmente los rechazarán?

Para aclarar el punto, intento hacerte decir que no aceptarán este razonamiento, pero es sólido.

Siempre es mejor prevenir que lamentar, IMO.

Answer 3

Al usar Unicode, deja la puerta abierta para la internacionalización si los requisitos cambian alguna vez y se requiere que use texto en otros idiomas además del inglés.

Además, en su nuevo proyecto siempre puede escribir envoltorios para las bibliotecas que convierten internamente entre ASCII y Unicode y viceversa.

Answer 4

No importa que el software no está traducido, si los usuarios utilizan caracteres internacionales entonces necesita el soporte Unicode para poder hacer correctamente las mayúsculas, clasificación, etc.

Answer 5

Muchos lenguajes (Java [y así la mayoría de las implementaciones de lenguaje basadas en JVM], C# [y por lo tanto la mayoría de las implementaciones de lenguaje basadas en .NET], Objective C, Python 3, ...) admiten cadenas Unicode por preferencia o incluso (casi) exclusivamente (tienes que salir de su forma de trabajar con "cadenas" de bytes en lugar de caracteres Unicode).

Si la empresa para la que trabaja tiene la intención de utilizar cualquiera de estos lenguajes y plataformas, sería recomendable comenzar a planificar una estrategia de soporte Unicode; un proyecto piloto en particular podría no ser una mala idea.

Answer 6

Unicode es como cooties. Una vez que "infecta" un área, por lo general es difícil contenerla dada la interconexión de las dependencias. Tarde o temprano, probablemente tendrá que vincular una biblioteca que sea compatible con Unicode y, por lo tanto, usará wchar_t's o similar. En lugar de ordenar entre los tipos de caracteres, es bueno tener cadenas consistentes en todo momento.

Por lo tanto, es bueno ser coherente. De lo contrario, terminarás con algo similar a la API de Windows que tiene una versión "A" y una versión "W" para la mayoría de las API, ya que no eran consistentes para empezar. (Y en algunos casos, Microsoft tiene abandoned creating "A" versions altogether.)

Answer 7

Las reglas extendidas del conjunto de caracteres científicos, técnicos y matemáticos.

¿En qué otro lugar puede decir ⟦∀c|c∈Unicode⟧ y algo similar técnico.

Answer 8

Bueno, los usuarios pueden saber y entender inglés, pero todavía pueden tener nombres 'locales'. Si permite que sus usuarios realicen cualquier tipo de entrada a su aplicación, es posible que deseen utilizar caracteres que no sean parte de ASCII. Si no admite Unicode, no tendrá forma de permitir estos nombres. Haría que sus usuarios adopten un nombre más simple simplemente porque la aplicación no sea lo suficientemente inteligente como para manejar caracteres especiales.

Otra cosa es que, incluso si el estándar ahora es que la aplicación solo se lanzará en inglés, también está bloqueando la posibilidad de internacionalización con ASCII, añadiendo al trabajo que debe hacerse cuando la política de la compañía decide que las traducciones son buenas La política de la compañía es buena, pero también se sabe que cambia.

Answer 9

La internacionalización es mucho más que texto en diferentes idiomas. Apuesto a que es el nicho del futuro en el mundo de TI. Diablos, ya lo es. Mucho se ha dicho, solo pensé en agregar algo pequeño. Aunque sus clientes ahora están satisfechos con el inglés, eso podría cambiar en el futuro. Y cuanto más espere, más difícil será convertir su código base. Incluso es posible que hoy tengan problemas con, por ejemplo, nombres de archivos u otros tipos de datos que guarde/cargue en su aplicación.

Answer 10

Esa es una muy buena pregunta. La única razón por la que se me ocurre que no tiene nada que ver con el texto I18n o que no está en inglés es que Unicode es particularmente adecuado para ser lo que podría llamarse un juego de caracteres de hub. Si considera que su sistema es un concentrador con sus dependencias externas como radios, desea aislar las conversiones de codificación de caracteres en los radios, para que su sistema central funcione de manera coherente con la codificación elegida. Lo que hace que Unicode sea un conjunto de caracteres ideal para el centro de su sistema es que reconoce la existencia de otros conjuntos de caracteres, define equivalencias entre sus propios caracteres y esos conjuntos de caracteres externos, y hay un proceso continuo donde se extiende para mantener con la innovación y la evolución de conjuntos de caracteres externos. Hay todo tipo de codificaciones raras: incluso cuando la documentación le asegura que el sistema externo o la biblioteca está utilizando ASCII simple, a menudo resulta ser una variante como IBM775 o HPRoman8, y lo bueno de Unicode es que no importa qué la codificación se le envía, hay muchas posibilidades de que haya una tabla en unicode.org que defina exactamente cómo convertir esos datos en Unicode y volver a salir sin perder información.Por otra parte, los equivalentes de a-z están bastante bien definidos en cada conjunto de caracteres, por lo que si sus datos están restringidos al alfabeto inglés estándar, ASCII puede funcionar tan bien como un conjunto de caracteres de centro.

Una decisión sobre la codificación es una decisión sobre dos cosas: qué conjunto de caracteres está permitido y cómo se representan esos caracteres. Unicode le permite usar casi cualquier personaje que se haya inventado, pero puede tener sus propias razones para no querer o no necesitar una opción tan amplia. Es posible que aún restrinja los nombres de usuario, por ejemplo, a combinaciones de az y guión bajo, tal vez porque tiene que ponerlos en un sistema LDAP externo cuyo conjunto de caracteres está restringido, tal vez porque necesita imprimirlos con una fuente que no lo hace cubre todo el Unicode, tal vez porque cierra los problemas de seguridad abiertos por los personajes similares. Si está utilizando algo como ASCII o ISO8859-1, la capa de almacenamiento/transmisión implementa muchas de esas restricciones; con Unicode, la capa de almacenamiento no restringe nada, por lo que podría tener que implementar sus propias reglas en la capa de aplicación. Esto es más trabajo: más programación, más pruebas, más estados posibles del sistema. La compensación para ese trabajo adicional es más flexibilidad, las reglas de nivel de aplicación son más fáciles de cambiar que las codificaciones del sistema.

Answer 11

Supongamos que su programa me permite poner mi nombre en él, en un formulario, un cuadro de diálogo, lo que sea, y mi nombre no se puede escribir con caracteres ASCII ... Aunque su programa está en inglés, los datos pueden Estar en otro idioma ...

Answer 12

Solo piense en un cliente que desee utilizar nombres como Schrödingers Cat para los archivos que guardó con su software. O imagine algunos Windows localizados con una traducción de Mis documentos que utiliza caracteres que no son ASCII. Esa sería la internacionalización que tiene, aunque no admite la internacionalización en absoluto, efectos en su software.

Además, tener la opción de apoyar la internacionalización más tarde siempre es algo bueno.

Answer 13

Si no tiene necesidad de cambiar a Unicode, entonces no lo haga. Estoy basando esto en el hecho de que pensaste que necesitarías cambiar el código no relacionado con el componente que ya tienes que cambiar para que todo funcione con Unicode. Si puede hacer que el componente/característica en la que está trabajando esté "listo para Unicode" sin expandir el código a muchos otros componentes (especialmente otros componentes sin buena cobertura de prueba), continúe y haga que esté listo para Unicode. Pero no agite toda la base de código sin necesidad comercial.

Si la necesidad del negocio surge más tarde, diríjalo a continuación. De lo contrario, no vas a necesitarlo.

Las personas en este hilo pueden suponer escenarios en los que se convierte en un requisito comercial. Ejecute esos escenarios con los gerentes de producto antes de considerarlos como escenarios que vale la pena abordar. Asegúrese de que sepan el costo de dirigirse a ellos cuando lo solicite.

Answer 14

No ha dicho qué idioma está utilizando. En algunos idiomas, cambiar de ASCII a Unicode puede ser bastante fácil, mientras que en otros (que no admiten Unicode) puede ser bastante difícil.

Dicho esto, tal vez en su situación no debe admitir Unicode: no puede pensar en una razón convincente por la que debe hacerlo, y hay algunas razones (es decir, su costo para cambiar sus bibliotecas existentes) en contra de las cuales. Quiero decir, tal vez 'idealmente' deberías, pero en la práctica podría haber alguna otra cosa más importante o más urgente para gastar tu tiempo y esfuerzo en este momento.

Answer 15

Si el programa recibe la entrada de texto del usuario, debe usar unicode; nunca se sabe qué idioma usará el usuario.

Answer 16

Es posible que su cliente potencial ya ejecute una aplicación que no sea unicode en un idioma que no sea el inglés y no podrá ejecutar su programa sin mover la configuración unicode de windows hacia adelante y hacia atrás, lo cual será un gran problema.

Answer 17

La razón para usar unicode es respetar abstracciones apropiadas en su diseño.

Simplemente acostúmbrate a tratar el concepto de con el texto correctamente. No es dificil. No hay motivo para crear un diseño roto incluso si sus usuarios son ingleses.

Answer 18

La empresa para la que trabajo, ** como política **, solo lanzará software en inglés, aunque tengamos clientes en todo el mundo.

1 motivo solamente: las políticas cambian, y cuando cambien, romperán su código existente. Período.

Design for evil, y tiene la posibilidad de no romper su código tan pronto. En este caso, use Unicode. Me sucedió en un sistema legado bursátil brasileño específico.

Answer 19

Los caracteres que están más allá de la gama ASCII de 7 bits también son útiles en inglés. ¿Alguien que usa su software incluso necesita escribir el signo €? O £? ¿Qué hay de distinguir "currículum vítae" de "currículum vitae"? Usted dice que es utilizado por científicos de todo el mundo, que pueden tener nombres como "Jörg" o "Guðmundsdóttir". En un entorno científico, es útil hablar sobre longitudes de onda como λ, unidades como Å, o ángulos como Θ, incluso en inglés.

Algunos de estos caracteres, como "ö", "£" y "€", pueden estar disponibles en codificaciones de 8 bits como ISO-8859-1 o Windows-1252, por lo que puede parecer que solo puede usar esas codificaciones y listo. El problema es que hay caracteres fuera de esos rangos que muchas personas usan con mucha frecuencia, por lo que muchos de los datos existentes están codificados en UTF-8. Si su software no comprende que al importar datos, puede interpretar el carácter "£" en UTF-8 como una secuencia de 2 caracteres de Windows-1252 y presentarlo como "Â £". Si este tipo de error no se detecta durante el tiempo suficiente, puede comenzar a confundir seriamente sus datos, ya que los pases múltiples de interpretaciones erróneas alteran sus datos cada vez más hasta que se vuelven irrecuperables.

Y es bueno pensar en estos problemas desde el principio en el diseño de su programa. Como las cadenas tienden a ser un concepto de muy bajo nivel que se enhebra en todo el programa, con muchas suposiciones sobre cómo funcionan implícitas en cómo se usan, puede ser muy difícil y costoso agregar soporte Unicode a un programa más adelante si nunca has pensado en el problema para empezar.

Mi recomendación es usar siempre bibliotecas y tipos de cadenas compatibles con Unicode siempre que sea posible, y asegúrese de que cualquier prueba que tenga (unidades, integración, regresión o cualquier otro tipo de pruebas) que trate cadenas trate de pasar algunas Unicode ata a través de su sistema para garantizar que funcionen y salgan ilesos.

Si no maneja Unicode, entonces le recomiendo asegurarse de que todos los datos aceptados por el sistema son de 7 bits limpios (es decir, no hay caracteres más allá del rango US-ASCII de 7 bits). Esto ayudará a evitar problemas con incompatibilidades entre codificaciones heredadas de 8 bits como la familia ISO-8859 y UTF-8.

Answer 20

Porque Internet está usando abrumadoramente Unicode. Las páginas web usan unicode. Los archivos de texto que incluyen los documentos de su cliente y los datos en sus portapapeles, son Unicode.

En segundo lugar Windows, es de forma nativa Unicode, y las API ANSI son un legado.

Las aplicaciones modernas deben usar Unicode cuando corresponda, que es casi en todas partes.

Answer 21

Yo diría que esta actitud expresaba ingenuidad, pero no podría deletrear ingenuidad solo en ASCII.

ASCII todavía funciona para algunos códigos solo de computadora, pero no es bueno para la fachada entre la máquina y el usuario.

Incluso sin el estilo de cooperación anticuado del neoyorquino, ¿cómo iba a hacer frente una pobre mujer a Zoë si sus empleadores usaban ese sistema?

Por desgracia, ella ni siquiera buscaría otro empleo, ya que la actualización de su currículum sería imposible, y ella tendría que reanudar en su lugar. ¿Cómo va a explicar eso a su prometida?