Software Internationalization Challenges and Solutions

Muy bien, soy Samuel, y después de esta charla, vas a saber cuál es el verdadero problema con la internacionalización del software y cómo algo llamado el Lake Exchange Control System es capaz de resolver este gigantesco problema que ha existido durante décadas.

Comencemos por el principio. ¿Qué era E1N del software? Significa que estás adaptando tu producto de software para diferentes mercados y demografías. Eso significa diseño, mensajes, traducciones, pagos y monedas. Usualmente lo haces porque quieres expandirte a diferentes mercados, pero no solo es expandirse a diferentes mercados. Puede ser que seas una empresa estadounidense y quieras dirigirte a la población de habla hispana en los EE.UU.

de manera más efectiva. Para hacerlo, tienes que internacionalizar, cambiar el diseño, implementar traducciones, yada yada. Ahora, en ambos casos, ya sea expansión global o dirigirse a una demografía en un mercado específico de manera más efectiva, todo se reduce al dinero. Por supuesto que sí. ¿Por qué? Bueno, si puedo dirigirme a las personas de manera más efectiva, más dinero. Si puedo expandirme a diferentes países, eso significa más clientes, más dinero.

Esa es una declaración audaz. Eres una empresa alemana, por ejemplo, y hay una herramienta que te permite adaptar tu pieza de software al mercado estadounidense, mercado brasileño, mercado indio, mercado chino, todo en un día. Ese es el objetivo, eso es para lo que tenemos que encontrar una solución, y en eso hemos estado trabajando durante los últimos dos años.

Ahora, ¿por qué hacemos esto de nuevo? Bueno, te ayudamos a adquirir más clientes, llevar tu producto al mundo, y en última instancia ayudarte a ganar más dinero. Esa es una gran propuesta de negocio.

Bien, ¿cuál es el problema real con la internacionalización? ¿Por qué hemos estado trabajando en ello durante más de dos años y la propuesta de negocio tiene tanto sentido, así que pensarías que ya existe algo por ahí, ¿verdad? La respuesta es no, porque el problema está algo oculto.

Verás, todos creen que la internacionalización es bastante simple. Haces algunas traducciones, aceptas una moneda diferente, tal vez ajustas el diseño. Es bastante simple, ¿verdad? La respuesta es sí. Si lo miras de forma aislada, eso no es realmente complicado. Lo que es complicado, sin embargo, es que todo necesita ser coordinado. La internacionalización del software es un problema de coordinación donde terminas con un proceso como este, donde de repente te das cuenta de que necesitas coordinar los esfuerzos de internacionalización entre desarrolladores, diseñadores, traductores, auditores, gerentes de producto y todos los demás que tocan el producto en un proceso que puede volverse extremadamente complejo extremadamente rápido.

Así que pasemos por ello como un ejemplo. Imagina que eres un desarrollador ahora mismo, y estás implementando una nueva pantalla de inicio de sesión. Lo que piensas como desarrollador es, la internacionalización es simple, ¿verdad? Solo necesito implementar algunas funciones T, llamarlas en mi código, y lo que hacen es buscar un mensaje en un archivo JSON, y eso es todo. Eso es internacionalización, ¿verdad? Bueno, para el desarrollador en este caso, sí, eso es probablemente todo. Pero entonces, ¿qué sucede después, verdad? La pantalla de inicio de sesión está implementada. ¿Dónde están las traducciones? Bueno, no existen en este punto. Así que tiene que haber alguien que le diga a los traductores, tienes que empezar a trabajar. Aquí es donde ya se desmorona porque ¿quién les dice que el traductor necesita empezar a trabajar? Es un proceso manual.

De acuerdo, por ahora, es un proceso manual. Los traductores se ponen a trabajar, ¿y qué es esto? Están trabajando en una aplicación diferente. Nunca había visto eso antes. Así que este es un editor CAT, editor de traducción asistida por computadora, y proporciona a los traductores una interfaz de usuario para crear traducciones. Suena simple, ¿verdad? Pero, ¿cómo llegan las traducciones del desarrollador al traductor y luego de vuelta al desarrollador? Hay un paso de entrega manual que incluye importar y exportar todas las traducciones de todas esas dos herramientas. Así que la biblioteca E1N y el editor CAT. Ya estás viendo que, oh, mierda, sí, tenemos mucho que coordinar. Pero, por supuesto, no termina ahí porque una vez que los traductores han terminado, ¿qué sucede después, verdad? Lo más probable es que los diseñadores necesiten revisarlo. Los diseñadores necesitan saber si las traducciones ahora están desbordadas y necesitan ajustar las interfaces de usuario. Así que todo el juego comienza de nuevo.

Ahora los traductores de alguna manera necesitan informar a los diseñadores y ser compatibles con la aplicación que los diseñadores usan. En este caso, quieren ver directamente en su herramienta de pantalla de UI si las traducciones funcionan para la UI. Y en este caso, está bien, les et vos creations parlent tous les langues. Lo siento, gente francesa. Están decidiendo, sí, funciona. Así que lo envían de vuelta a los traductores y así sucesivamente.

Ya vemos un problema importante aquí. El problema principal es que, sí, necesitamos coordinar entre todas esas personas, pero cada uno tiene un trabajo diferente. Los desarrolladores tienen el trabajo de una biblioteca e1n donde necesitan asegurarse de que las traducciones se muestren. Eso es muy diferente del trabajo de los traductores que, ya sabes, tienen el trabajo de crear y gestionar traducciones. Lo mismo ocurre con los diseñadores. Tienen un trabajo diferente y su trabajo es asegurarse de que la UI funcione en todos los mercados en los que la aplicación o pieza de software está activa. Lo mismo se aplica a los auditores, gerentes de producto y todos los demás. Todos tienen una aplicación de elección para su trabajo.

Y el problema es que el status quo actual es que, sí, hay buenas soluciones para desarrolladores. Y, sí, hay buenas soluciones para diseñadores y para traductores. Auditores no en este momento y gerentes de producto también inestables. Pero para desarrolladores, diseñadores y traductores, existen buenas soluciones. El problema es que se requieren cientos de integraciones entre ellos para lograr que todo se haga y cualquier integración siempre significa que hay una pérdida de datos. Correcto. Esta aplicación dice algo que esta aplicación no entiende y el traductor dice algo que los diseñadores no entienden. Todo explota. Recuerda, nuestro objetivo es ayudar a una empresa a globalizarse en un día. Si tenemos este problema, cientos de integraciones, eso tomará más de un día. Así que esto no funcionará. El segundo problema, sin embargo, es el pipeline. Correcto. Es bueno si tienes una aplicación que funciona para todo, pero necesitas coordinar este pipeline. Y esto es algo donde nosotros como ingenieros de software y, ya sabes, la audiencia es principalmente desarrolladores en este momento. Ya tenemos un sistema así.

Se llama Control de Versiones y pipelines de CI CD. Sabemos exactamente cuándo hay algo mal en el código. Aplica los mismos principios ahora a la internacionalización del software y rápidamente te das cuenta de que si estás implementando una pantalla de inicio de sesión, debería haber un pipeline de CI CD ejecutándose que te diga oye, escucha, falta una traducción. Los traductores necesitan crear las traducciones. Y una vez que los traductores han terminado, otro pipeline se ejecuta que dice, oye, los diseñadores ahora necesitan revisar el diseño. Y después de que los diseñadores han aprobado la revisión, pasa a la auditoría. Y solo cuando la auditoría lo aprueba, porque no quieres estar legalmente en problemas en algunas regiones. Si tu proyecto se vuelve grande, cada texto, todo lo que muestras al usuario será auditado. Solo cuando la auditoría dice sí, entonces los desarrolladores dicen sí, los traductores dicen sí, los diseñadores dicen sí y la auditoría dice sí, entonces lo despliegas al usuario. Eso es CI CD en resumen. Y hemos tenido eso durante los últimos 10 años en la ingeniería de software.

OK, en conclusión, ¿cómo podemos alcanzar el objetivo de hacer que una empresa sea global en un día? Se necesitan dos cosas. Primero, se necesita un formato de archivo interoperable para aplicaciones. Necesitamos un formato de archivo donde cada aplicación pueda trabajar sobre él. No más integraciones o incompatibilidades entre aplicaciones. Segundo, necesitamos algo como el control de versiones que tienen los ingenieros de software, pero ahora lo necesitamos en el contexto de la internacionalización del software. Y llamamos a este sistema Lix, el sistema de control de cambios. Por qué lo llamamos un sistema de control de cambios y no un sistema de control de versiones, lo explicaré en un segundo.

Primero, veamos el formato de archivo interoperable para aplicaciones. Esta es la solución que estamos esbozando con Inlang. Será un formato de archivo abierto, y puedes construir aplicaciones sobre él para todas las personas y equipos que están involucrados en el pipeline de internacionalización. El gran beneficio es que todas las aplicaciones que la gente usa, simplemente abren el mismo archivo. No hay importación-exportación entre todas esas aplicaciones, lo que elimina enormemente la sobrecarga y asegura que no haya pérdida de datos entre las aplicaciones. Comparado con el antes y el después, así que está el status quo actual, existen buenas soluciones de polling para desarrolladores, tal vez diseñadores, tal vez traductores, pero realmente quieres un formato de archivo para simplemente construir todas las aplicaciones sobre él porque entonces obtienes interoperabilidad. Bien, eso es hermoso.

Como mencioné, necesitas una segunda pieza, ¿verdad? Resolver la pieza de la aplicación es una cosa. ¿Cómo resolvemos el problema de CICD? Bueno, nuestra idea es que tendrás este formato de archivo Inlang, y vamos a tener este sistema de control de cambios Lix, y podrás arrastrar y soltar este archivo Inlang en el sistema de control de cambios, y lo que obtienes es control de cambios. Lo que es control de cambios, obtendrás un gráfico de cambios para todo lo que sucedió en ese archivo Inlang. Así que alguien cambió la traducción, lo sabes. La auditoría lo aprobó, lo sabes. Y con esa información de cambio, puedes comenzar a construir colaboración basada en archivos. Esto es muy novedoso, nunca visto antes, pero también puedes comenzar a automatizar enormemente eso. Lo que nosotros como ingenieros de software tenemos con CICD, ahora lo estamos llevando a la internacionalización, localización, globalización, como quieras llamarlo, del software a través del sistema de control de cambios Lix. ¿Por qué se llama control de cambios y no control de versiones? Porque se ejecuta en el navegador web, que es un diferenciador, pero segundo, también comprende cambios en todo tipo de archivos. No solo funciona para archivos de texto. El archivo Inlang es un archivo binario y el sistema de control de cambios Lix es capaz de comprender lo que cambió en este archivo binario y es capaz de hacer eso para cualquier otro archivo binario que puedas imaginar a través de plugins. Así que lo llamamos control de cambios porque comprende cambios en archivos y no solo los versiona. Comprende que la traducción en este archivo binario cambió. Bien. Así que eso es bastante bueno. Ahí vamos.

Entonces, para recapitular, lo que necesitas para resolver la internacionalización del software es primero un archivo interoperable, que sea abierto para que las aplicaciones puedan construir sobre él y emerja un ecosistema. Un ecosistema de aplicaciones para traductores, diseñadores, auditores, y así sucesivamente. Y segundo, necesitas poder controlar todos los cambios y coordinar entre todos esos diferentes grupos. Y para eso estamos construyendo el sistema de control de cambios Lix.

Bien. ¿Por qué es esto hermoso? Porque obtienes ese gráfico de cambios y así sucesivamente. Hemos estado en esto por más de dos años y tenemos un prototipo del archivo Inlang de esto, que algunas personas ya usan. Está en forma de un directorio, pero me complace anunciar que el 16 de diciembre, vamos a lanzar una pre-lanzamiento público del sistema de control de cambios Lix. Como mencioné, no solo funcionará para archivos Inlang, sino para todo tipo de archivos que puedas imaginar y podrás construir tus propios plugins y obtener control de cambios para ello. Y luego, en el primer trimestre de 2025, seguiremos con la especificación del archivo .inlang que nuestros usuarios actuales aún no han visto. Pero para todos los demás, esta será la versión final 1.

0, por así decirlo, del ecosistema Inlang y formato de archivo. Bien. Espero que hayas aprendido un poco de la charla. Si te llevas algo de esto, la internacionalización del software se volverá realmente simple y el sistema de control de cambios Lix no solo es beneficioso para la internacionalización del software.