Resumen

  • La publicación del 5 de octubre añade reglas de referencia para la escritura javanesa y la escritura silábica aborigen canadiense unificada, y actualiza otras siete. Las variantes entre escrituras convierten el anuncio en un cambio conectado, no en dos incorporaciones aisladas.
  • Estas reglas de segundo nivel orientan el diseño y la revisión de tablas IDN de los registros. Su cobertura no demuestra delegación de dominios de nivel superior, compatibilidad universal de aplicaciones ni adopción efectiva.

Análisis

Una lista de idiomas puede parecer un catálogo. La publicación de ICANN del 5 de octubre se entiende mejor como un mapa de dependencias.

ICANN publicó reglas de generación de etiquetas (LGR) de referencia de segundo nivel para la escritura javanesa y la escritura silábica aborigen canadiense unificada (UCAS), y actualizó otras siete: escritura árabe, idioma árabe, idioma inuktitut, idioma japonés, escritura japonesa, escritura latina y el conjunto completo de variantes latinas. La entidad indica que su colección ahora abarca 30 escrituras y 32 idiomas. Esos totales describen el material de referencia publicado; no cuentan cuántos idiomas funcionan de punta a punta en cada registrador, navegador, sistema de correo o aplicación.

Las notas de cambio muestran por qué contar las incorporaciones no basta para entender el trabajo operativo. La nueva regla UCAS viene acompañada de variantes entre escrituras en las reglas del idioma inuktitut. Un carácter latino añadido para apoyar las lenguas algonquinas de Canadá también modifica variantes entre escrituras en el conjunto completo de variantes latinas. Las reglas del idioma y la escritura japoneses se alinean con la versión 6 de las reglas de generación de etiquetas de la zona raíz. Los cambios en la escritura árabe respaldan la escritura pegón de Indonesia.

Cada alta está vinculada con otras reglas que los registros y quienes revisan sus tablas quizá deban tomar en cuenta.

Eso importa porque estas reglas alimentan una decisión concreta. ICANN las presenta como referencias para que los operadores de registros genéricos de nivel superior diseñen tablas de nombres de dominio internacionalizados (IDN). También las usa para revisar, en materia de seguridad y estabilidad, las tablas que presentan los registros. La tabla determina qué etiquetas puede aceptar una zona según su política y cómo trata sus variantes. Por eso, un cambio en un archivo de referencia puede afectar el análisis del registro más allá de la escritura mencionada en el titular.

Esto no significa que los registros ya hayan adoptado las versiones de octubre ni que todas las tablas afectadas deban cambiar del mismo modo. Es una cuestión de control de versiones: ¿qué conjunto de referencia usó el operador, qué cambió y qué etiquetas o relaciones entre variantes debe volver a probar? Un registro que solo siga las dos nuevas escrituras podría pasar por alto una actualización relacionada en su tabla IDN o en el procedimiento de revisión.

También importa distinguir los niveles. Las LGR de referencia de segundo nivel se refieren a las tablas IDN usadas bajo dominios genéricos de nivel superior. La Guía del Solicitante del ciclo de 2026 emplea la versión 6 de las reglas de la zona raíz para validar cadenas de nivel superior y calcular sus variantes. Ambos sistemas se conectan mediante alineaciones y dependencias técnicas, pero responden preguntas distintas. Una regla de referencia de segundo nivel no aprueba por sí misma una nueva extensión, no delega una etiqueta ni concede al titular un derecho para usarla.

El resultado de la consulta pública de ICANN registra 33 comentarios pertinentes: 32 apoyaron las reglas nuevas y actualizadas propuestas, y uno señaló una errata y pidió una aclaración sobre la escritura javanesa. Ese recuento informa de las respuestas recibidas por ICANN. No es una votación de todos los registros, de todos los usuarios de esas escrituras ni de cada comunidad lingüística. La descripción del trabajo como «desarrollado con las comunidades» también debe leerse dentro de ese marco: hubo consulta a expertos y grupos pertinentes, pero el recuento tiene un ámbito concreto.

La publicación tampoco demuestra aceptación universal. Las reglas de etiquetas legibles por máquina ayudan a un registro a evaluar si una etiqueta encaja en su tabla y cómo tratar variantes relacionadas. No hacen que un formulario web acepte una dirección, que un servicio de correo la entregue ni que un programa la almacene y muestre bien. ICANN deja abierta la inclusión futura de más idiomas y escrituras cuando haya aportes comunitarios pertinentes. La cobertura publicada es una base para la revisión técnica, no una medida de uso.

Para los registros, la respuesta práctica es tratar la publicación como un conjunto de cambios. Comparar la versión vigente con los archivos nuevos, relacionar cada cambio con la propia tabla IDN, probar las etiquetas y variantes afectadas y coordinar las fechas de política e implementación con los proveedores de servicios registrales. Los vínculos entre escrituras merecen especial atención: los usuarios y los registros manejan etiquetas, no listas aisladas de puntos de código.

La pregunta importante no es solo cuántas escrituras añadió ICANN. Es si el conjunto sigue siendo coherente a medida que se amplía la cobertura. La publicación de octubre muestra que una incorporación puede propagarse: incluir una escritura puede llevar a reconsiderar variantes de otro idioma, mientras que añadir un carácter puede alterar un conjunto completo de variantes entre escrituras. El catálogo también es una superficie de mantenimiento.