Durante casi una década, un pequeño detalle del idioma turco estuvo provocando que el lenguaje de programación Kotlin —uno de los pilares del desarrollo moderno para Android— generara errores aparentemente inexplicables. Lo que comenzó como un mensaje en un foro en 2016 terminó convirtiéndose en un sorprendente hito de la historia de la ingeniería de software: un idioma humano que consiguió ‘romper’ un lenguaje de programación.
Un error difícil de entender
En marzo de 2016, el ingeniero turco Mehmet Nuri Öztürk publicó un mensaje en el foro de Kotlin. Su código no compilaba, y el compilador mostraba un error críptico:
Unknown compiler message tag: INFO
Nadie sabía qué significaba. Kotlin acababa de lanzar su versión 1.0, y todo indicaba que se trataba de un fallo menor. Sin embargo, pasaron meses antes de que otro programador, Muhammed Demirbaş, sospechara que el problema no tenía nada que ver con el código… sino con el idioma del sistema operativo.
La “I” turca que confundió al compilador
En la mayor parte de lenguas con alfabeto latino, la letra «I» se convierte en «i» al pasar a minúsculas. Pero en turco existen dos variantes de la letra:
- «i» con punto → mayúscula “İ”
- «ı» sin punto → mayúscula “I”
Así, mientras «INFO».toLowerCase() en inglés produce «info», en turco devuelve «ınfo», con una ı sin punto. Esa diferencia minúscula provocaba que el compilador de Kotlin no encontrara la categoría de mensaje esperada y fallara con un error incomprensible.
El error se documentó oficialmente como KT-13631: «Compilation fails on Turkish locale because of locale-sensitive uppercasing». Pero quedó enterrado entre cientos de tickets y no se solventó. Nadie sospechaba que aquel detalle iba a causar más estragos años después.
Cuando las corrutinas heredaron el bug
En 2018, Kotlin lanzó su versión 1.3 con una de sus funciones estrella: las corrutinas, un sistema para manejar tareas asíncronas de manera elegante. Fue entonces cuando el problema lingüístico resurgió con fuerza.
El desarrollador turco Kemal Atlı reportó un error al actualizar su app:
java.lang.NoSuchMethodError: No static method boxİnt(I)Ljava/lang/Integer;
La clave estaba en el nombre del método: boxİnt(), con una “İ” mayúscula con punto. El compilador, al generar código para las corutinas, usaba la función capitalize() para construir nombres de métodos como boxInt(). Pero, al ejecutarse en un sistema configurado en turco, convertía “int” en “İnt”, y el compilador buscaba un método que no existía.
Ese error concreto se resolvió en 2019 al especificar explícitamente el uso del idioma inglés en la llamada a capitalize(Locale.US). Pero ya era evidente que el problema iba mucho más allá de una simple función.
Un tercer bug y la solución definitiva
Dos años después, otro desarrollador turco, Muhittin Kaplan, reportó un nuevo fallo: su sencillo programa con intArrayOf() fallaba con un NoSuchMethodError. De nuevo, el culpable era el mismo: el método decapitalize() había devuelto «ıntArray» (con ı sin punto) en lugar de «intArray».
Finalmente, la respuesta del equipo de Kotlin fue contundente: buscar y corregir todas las operaciones de cambio de mayúsculas/minúsculas dependientes del idioma en el compilador. En total, 173 líneas de código y 53 archivos fueron modificados, reemplazando las funciones toLowerCase(), toUpperCase(), capitalize() y decapitalize() por versiones independientes del ‘locale’.
En mayo de 2021, con el lanzamiento de Kotlin 1.5, el histórico bug KT-13631 se cerró oficialmente, cinco años después de su primer reporte.
Kotlin cambia su propio lenguaje por culpa de un idioma humano
El impacto fue tan profundo que el equipo de JetBrains publicó la propuesta KEEP-223: “Locale-agnostic case conversions by default”, para rediseñar por completo la forma en que Kotlin maneja las conversiones de mayúsculas y minúsculas.
A partir de Kotlin 1.5 se introdujeron las nuevas funciones uppercase() y lowercase(), que ignoran el idioma del sistema. Y desde Kotlin 2.1 (noviembre de 2024), el uso de las antiguas toLowerCase() y toUpperCase() genera un error de compilación. Incluso capitalize() desapareció definitivamente, reemplazada por replaceFirstChar { … }.
En otras palabras: el idioma turco obligó a cambiar la biblioteca estándar de Kotlin y a redefinir funciones que existían desde su nacimiento.
Más que un bug: una lección sobre lenguaje y cultura
Al final, un carácter sin punto fue suficiente para confundir compiladores, bloquear proyectos y obligar a los ingenieros de JetBrains a replantear cómo su lenguaje debía entender el texto. Pero el problema no estaba en la lengua turca ni en los programadores de Kotlin, sino en una presunción que demostró ser injustificada: que el ‘alfabeto inglés’ (la variante inglesa del alfabeto latino, siendo precisos) era el estándar universal para la informática.
Vía | Medium
Imagen | Marcos Merino mediante IA
–
La noticia
Un lenguaje humano obligó a cambiar el lenguaje Kotlin: estuvo cinco años generando bugs antes de que lo resolvieran
fue publicada originalmente en
Genbeta
por
Marcos Merino
.
