Internacionalizar la notación matemática: números, símbolos y división larga en cinco idiomas

Matriz de notación

Convención	en-US	en-GB	es-MX	es-ES	fr-FR	pt-BR	pt-PT	de-DE	Fuente
Separador decimal	.	.	.	,	,	,	,	,	[1]
Separador de agrupación de dígitos (práctica común)	, (1,234,567)	,	,	. (1.234.567)	espacio/. (1 234 567)	.	.	.	[1]
Agrupación recomendada por el BIPM	espacio fino	espacio fino	espacio fino	espacio fino	espacio fino	espacio fino	espacio fino	espacio fino	[1]
Separador de lista cuando la coma es el decimal	,	,	,	; (para evitar choque)	;	;	;	;	[1], práctica general
Símbolo de división que se enseña	÷ luego /	÷ luego /	÷	÷ / :	:	÷	÷ / :	:	[5][6]
Símbolo de multiplicación que se enseña	×	×	×	×	×	×	×	· (punto)	[6]
Layout de la división larga	tablero de EE. UU., corchete, cociente arriba	tablero de EE. UU.	layout anglosajón, resta mental	“potencia”: divisor a la derecha de `	`, cociente abajo	“potencia”: divisor a la derecha de `	`, cociente abajo	europeo: divisor a la derecha de `	`, cociente abajo
Intervalo, abierto	(0,1)	(0,1)	(0,1)	(0,1)	]0,1[ (enseñado en la escuela)	(0,1)	(0,1)/]0,1[ (varía)	(0,1) (también ]0,1[ en algunos currículos)	[4]
Intervalo, semiabierto	[0,1)	[0,1)	[0,1)	[0,1)	[0,1[	[0,1)	[0,1)/[0,1[	[0,1)/[0,1[	[4]
Nombre de escala para 10⁹	billion	billion (desde 1974)	mil millones	mil millones	milliard	bilhão (excepción de escala corta)	mil milhões	Milliarde	[2][3]
Nombre de escala para 10¹²	trillion	trillion	billón	billón	billion	trilhão	bilião	Billion	[2][3]
Estructura de los números adolescentes	regular (thirteen–nineteen irregular también en EN)	igual	dieciséis (fusionado)	dieciséis (fusionado)	seize (raíz opaca)	dezesseis	dezasseis	sechzehn (regular, pero 21 = “einundzwanzig”, invertido)	[7], conocimiento general (marcado como no verificado para la fecha exacta de la RAE)
Estructura de las palabras 70/80/90	regular (seventy/eighty/ninety)	igual	setenta/ochenta/noventa (regular)	igual	soixante-dix/quatre-vingts/quatre-vingt-dix (BE/CH: septante/nonante)	setenta/oitenta/noventa (regular)	igual	siebzig/achtzig/neunzig (regular)	[7]
Categorías plurales de CLDR	one, other	one, other	one, many, other	one, many, other	one, many, other	one, many, other	one, many, other	one, other	[8][9]

Nota: la fila de notación de intervalos para pt-PT/de-DE está marcada como “varía” porque los currículos difieren según el libro de texto/región y la fuente de Wikipedia [4] documenta la existencia de la convención de corchete invertido (Bourbaki) sin dar una tabla de adopción país por país; trátese como direccionalmente correcto, no confirmado de forma independiente para cada locale nombrado.

Hallazgos

1. El marcador decimal: la posición del BIPM/ISO, y por qué México es la excepción

La 22ª Conferencia General de Pesos y Medidas (2003) declara que el marcador decimal “shall be either the point on the line or the comma on the line” — ambos son igualmente válidos bajo el SI [1]. ISO 80000-1 repite esta neutralidad, aunque las directivas editoriales de ISO/IEC usan la coma en el propio texto de los estándares [1]. La agrupación de dígitos es una cuestión aparte: la política del BIPM desde 1948 (reafirmada en 2003) recomienda un espacio fino para agrupar millares (p. ej., 20 000, 1 000 000), específicamente para evitar por completo la ambigüedad entre coma y punto [1]. En la práctica casi nadie en el software de consumo sigue la recomendación del espacio fino; los países en cambio usan como agrupador el símbolo que no sea ya su marcador decimal — los países con decimal de coma (España, Francia, Alemania, Brasil, Portugal) usan el punto para agrupar, y los países con decimal de punto (EE. UU., Reino Unido, México, Canadá anglófono) usan la coma [1]. México usa el punto, a diferencia de España, a pesar de que ambos son hispanohablantes [1] — esta es una división documentada dentro de la misma familia lingüística y el lugar más probable donde un fallback genérico de locale “es” se rompe en silencio.

2. La colisión de la coma como separador de lista

Donde el marcador decimal es una coma, usar la coma como separador de lista/argumento es ambiguo (3,5 podría ser “3.5” o “la lista 3, 5”). La solución convencional en los locales con decimal de coma es usar un punto y coma como separador de lista/argumento (las fórmulas de hojas de cálculo en fr-FR/de-DE/es-ES hacen exactamente esto) [1, práctica general]. Esto importa directamente para cualquier cadena de interfaz que liste valores numéricos en línea, y para las exportaciones tipo CSV donde una cadena ingenua de números decimales unidos por comas no es parseable en un locale con decimal de coma.

3. Los símbolos de división y multiplicación

La instrucción aritmética en países angloparlantes usa ÷; la instrucción francesa y alemana comúnmente usa los dos puntos : para la división, consistente con el layout de división larga descrito abajo [5][6]. Para la multiplicación, la convención educativa alemana favorece el operador de punto · sobre ×, en parte porque × se parece visualmente a la letra x usada como variable, y en parte porque un punto alzado no choca con la coma decimal alemana al escribir a·b junto a números decimales [6]. El asterisco * es una convención de la era de la computación (el ASCII carecía de ×) y no es un símbolo que se enseñe en el salón de clases en ninguno de nuestros cinco idiomas [6] — debería aparecer solo en contextos de código/entrada (p. ej., un campo de entrada estilo calculadora), nunca en contenido instruccional renderizado.

4. El layout de la división larga — el ítem de mayor riesgo para un tutor paso a paso

El artículo de Wikipedia sobre la división larga documenta al menos cuatro layouts estructuralmente distintos relevantes para nuestros locales [5]:

• EE. UU./Reino Unido (“bus stop”/tablero): no hay ningún símbolo ÷ ni : — un paréntesis derecho o una barra vertical separa el divisor del dividendo, y el cociente se escribe arriba del dividendo, separado por un vínculo (línea superior). Este es el layout que la mayoría del ed-tech en inglés asume que es “la” división larga.
• Francia/España/Portugal (“potencia” o “galera”): el divisor se coloca a la derecha del dividendo, separado por una barra vertical; el cociente se escribe abajo del divisor, bajo una línea horizontal, y las restas intermedias caen en cascada por la columna izquierda. Ejemplo: 127|4 con el cociente 31,75 apareciendo debajo de la barra.
• Alemania/Austria/Suiza: la división larga se escribe como una ecuación horizontal — 127 : 4 = 31,75 — con el trabajo mostrado en una columna vertical de borrador aparte, no en un tablero encajonado [5].
• México: usa visualmente el tablero de estilo anglosajón, pero con una diferencia pedagógica — solo se escribe el resultado de cada paso de resta; se espera que la resta misma se haga mentalmente, produciendo un tablero visualmente más escueto que la versión estadounidense [5]. (Los salones mexicanos llaman informalmente a este layout “galera” o “casita” — este nombre coloquial es conocimiento general de la pedagogía de primaria mexicana, no algo que el propio texto de Wikipedia consultado haya usado, así que hay que tratar el término, no la descripción del layout, como no verificado.)
• Brasil: a diferencia del resto de Latinoamérica, Brasil (junto con Bolivia, Paraguay y Venezuela según la misma fuente) usa el layout estilo potencia europeo en lugar del anglosajón [5] — lo que significa que una simple división de locale “es-LatAm vs. pt-BR” ni siquiera es suficiente; el layout de Brasil se parece más al de España que al de México.

Un tutor que muestra “pasos” para la división larga no puede usar una sola plantilla visual fija — necesita como mínimo cuatro renderizadores distintos (EE. UU./Reino Unido, potencia/europeo, ecuación alemana, escueto-mexicano) seleccionados por locale, no por idioma.

5. La notación de intervalos

ISO 31-11 documenta dos convenciones válidas para excluir un extremo: reemplazar el corchete por un paréntesis ((0,1), [0,1)), o invertir el corchete (]0,1[, [0,1[) [4]. La forma de corchete invertido fue introducida por el colectivo Bourbaki (francés) y es la forma que se enseña en los currículos de secundaria franceses (y, según conocimiento general no confirmado de forma independiente en el texto consultado, belgas); la forma de paréntesis domina la instrucción en inglés, español y portugués, y los currículos alemanes usan ambas dependiendo del libro de texto [4]. Este es un caso donde el renderizado “correcto” es una marca por locale (a veces por currículo) en lugar de un mapeo fijo desde el código de idioma.

6. Escala larga vs. escala corta — cinco idiomas, cinco/seis respuestas

La escala corta (billón = 10⁹, cada término nuevo ×1,000) la usa EE. UU. siempre, y el Reino Unido desde una decisión gubernamental de 1974 anunciada públicamente por el primer ministro Harold Wilson, adoptando “billion = 1,000 million” como la convención internacional/estadounidense [2]. La escala larga (billón = 10¹², milliard/mil millones/mil milhões = 10⁹ como término intermedio) la usan Francia (que revirtió a la escala larga en 1948 después de haber popularizado originalmente la escala corta en todo el mundo) [3], España y México (escala larga; “mil millones” es el término cotidiano para 10⁹ en lugar de una palabra nativa cercana a “billón”) [2], Alemania (Milliarde = 10⁹, Billion = 10¹²) [2][3], y Portugal (bilião = 10¹², mil milhões = 10⁹) [2]. Brasil es la excepción dentro del portugués: a diferencia de Portugal, el portugués brasileño usa la escala corta — “bilhão” = 10⁹ [2]. Así que a través de nuestros cinco idiomas/ocho locales, el grupo de escala corta es {en-US, en-GB, pt-BR} y el grupo de escala larga es {es-MX, es-ES, fr-FR, pt-PT, de-DE} — la división atraviesa tanto el inglés como el portugués, no sigue las líneas de idioma.

7. La estructura de las palabras numéricas y su efecto en aprender a contar

Tres diferencias estructurales (no solo léxicas) importan para la interfaz de conteo temprano y los scripts de TTS:

• La inversión alemana: los números de dos dígitos nombran el dígito de las unidades antes que el de las decenas y los unen con “und” — 21 es “einundzwanzig” (literalmente “uno-y-veinte”), el reverso del orden escrito de los dígitos. Este es un mapeo cognitivo genuinamente distinto entre la forma hablada y la escrita, no una decisión de traducción.
• Los restos vigesimales del francés: 70 es “soixante-dix” (sesenta-diez), 80 es “quatre-vingts” (cuatro-veintenas), 90 es “quatre-vingt-dix” (cuatro-veintena-diez) en el francés metropolitano; los hablantes de francés belga y la mayoría de los suizos usan en cambio los términos decimales regulares “septante” (70) y “nonante” (90), con el 80 permaneciendo como “quatre-vingts” en Bélgica y siendo mayormente regular (“huitante”, históricamente “octante”) solo en algunos cantones suizos — Ginebra, Neuchâtel y Jura conservan las formas metropolitanas [7]. Un solo locale “fr” no puede asumir un único conjunto de palabras numéricas ni siquiera dentro de la Europa francófona.
• Los números adolescentes fusionados vs. separados en español: “dieciséis/diecisiete/dieciocho/diecinueve” (16–19) son las formas fusionadas estándar modernas frente a la forma históricamente atestiguada y separada “diez y seis” — esta fusión/historia está bien documentada en la pedagogía del español en general, pero el fallo exacto de la RAE y su fecha no se pudieron confirmar de forma independiente con las fuentes consultadas en esta sesión; trátese la fecha específica de la RAE como no verificada, aunque la existencia de ambas formas no está en duda.

Lo que está en juego en ciencia del aprendizaje está establecido en la literatura de desarrollo cognitivo: los idiomas del este de Asia (chino, japonés, coreano) construyen las palabras numéricas con una estructura base-10 totalmente transparente (13 como “diez-tres” en lugar de “trece”), y las comparaciones entre países (Miura y colegas, comparando China, Francia, Japón, Corea, Suecia y EE. UU.) encontraron que esta transparencia se correlaciona con una comprensión temprana más fuerte del valor posicional y con representaciones mentales base-10 del número en niños pequeños [11][12]. Una línea de trabajo más reciente pone a prueba específicamente y complica en parte la fuerza de esta “explicación lingüística”, encontrando el efecto real pero modulado por otros factores instruccionales [13][14]. La conclusión práctica para Math Challenge: los ejercicios de conteo en alemán, francés y español para el grupo de edad más joven no se pueden producir traduciendo literalmente una secuencia de conteo al estilo inglés o chino — las propias palabras de conteo codifican una estructura distinta, así que el contenido de secuencias de conteo debe autorarse de forma nativa por idioma, incluyendo los rangos irregulares, no traducirse por máquina.

8. Las reglas plurales (CLDR) y la expansión de texto en alemán

Las categorías plurales de CLDR no son un binario “singular/plural” — son un conjunto de categorías gramaticales definidas por locale, según propiedades numéricas del operando (entero/decimal, dígitos finales, magnitud), y el número de categorías difiere por idioma: el inglés y el alemán usan dos categorías (one, other), cada una disparada específicamente por i = 1 and v = 0 (un valor entero de exactamente 1, sin dígitos decimales visibles) [9]. El francés, el español y el portugués usan tres categorías (one, many, other); notablemente en estos idiomas la categoría one también cubre el 0 en algunos conjuntos de reglas (francés: i = 0,1), lo que significa que “0 elementos” se pluraliza como “1 elemento” en lugar de como “5 elementos” — lo opuesto de la suposición por defecto del inglés de que cualquier cosa que no sea exactamente 1 es plural [9]. Cualquier cadena de interfaz con un conteo (“Resolviste {n} problemas”) debe pasar por ICU MessageFormat/Intl.PluralRules en lugar de una verificación fija tipo n === 1 ? singular : plural, o las cadenas de conteo cero en francés/español/portugués se leerán agramaticalmente. Por separado, es bien sabido que el alemán resulta 20–35% más largo que el inglés para cadenas de interfaz equivalentes debido a la composición de palabras — este es un hecho de localización general y ampliamente documentado, no algo reconfirmado mediante una búsqueda específica en esta sesión, y debe tratarse como una restricción de presupuesto de layout (probar con pseudolocalización, no solo con texto alemán real, ya que las cadenas en alemán pueden dispararse mucho más largas que el promedio en términos compuestos específicos).

9. La disponibilidad de voces TTS por locale

Esta es una pregunta de ingeniería/inventario de proveedores más que de lingüística, y no se pudo resolver con una fuente citable y actual en esta sesión (la cobertura de SpeechSynthesis.getVoices() del navegador depende del SO/navegador y cambia sin una referencia canónica estable; la lista de idiomas del modelo melotts de Cloudflare Workers AI y la matriz de locale/voz de cualquier proveedor de TTS de terceros deben verificarse directamente contra la ficha de modelo actual del proveedor al momento de la implementación, no asumirse a partir de este reporte). Márquese como no verificado y que requiere una verificación directa contra el proveedor de TTS que se elija, con atención particular a si pt-BR y pt-PT tienen voces distintas (a menudo no) y si es-MX y es-ES tienen voces distintas (cada vez más sí, pero no universalmente).

10. Las capacidades de Intl.NumberFormat / Intl.PluralRules

Intl.NumberFormat maneja de forma nativa la selección del separador decimal/de agrupación, el sistema de dígitos (p. ej., dígitos indoarábigos), y el formato style: "unit"/"currency"/"percent" según la etiqueta de locale BCP-47, y expone formatToParts() para construir salida con estilo personalizado y formatRange() para mostrar algo tipo intervalo [10]. Es consciente del locale en la salida, pero no dice nada sobre el parseo de locale en la entrada — no existe un Intl.NumberFormat.parse(); parsear la entrada de un usuario formateada según su locale (un niño alemán escribiendo “3,5”) tiene que manejarse en el código de la aplicación, típicamente usando formatToParts() sobre un valor conocido para descubrir los caracteres decimal/agrupador del locale actual y luego normalizar la entrada del usuario contra ese mapeo descubierto antes de llamar a Number()/parseFloat(). Intl.PluralRules (emparejado con los datos de CLDR, ver §8) resuelve la categoría plural para un número dado en un locale dado y es la primitiva correcta para manejar cadenas pluralizadas al estilo ICU MessageFormat.

Implicaciones de diseño

1. Guardar los ítems como un AST estructurado, no como texto renderizado — veredicto: AST. Un ítem matemático (ecuación, intervalo, problema de división larga) debe guardarse como una estructura semántica agnóstica de locale (operador, operandos, precisión, magnitud) y renderizarse a texto/visuales solo en el límite de presentación. Guardar cadenas ya renderizadas (p. ej., “3,5 ÷ 2 = 1,75”) convierte cada locale en una bifurcación de contenido; guardar un AST convierte al locale en un parámetro de renderizado.
2. El parseo de respuestas debe aceptar la entrada decimal correcta para el locale. Un niño alemán o francés que escriba “3,5” debe ser aceptado como 3.5; un niño de es-MX o en-US que escriba “3.5” también debe ser aceptado. Implementar un normalizador consciente del locale (descubrir los caracteres decimal/agrupador del locale vía Intl.NumberFormat().formatToParts(), quitar/convertir según corresponda) en lugar de una sola expresión regular global.
3. La división larga necesita al menos cuatro renderizadores paso a paso distintos, seleccionados por una configuración de locale (o de región de currículo explícita), no solo por código de idioma: tablero de EE. UU./Reino Unido, potencia de Francia/España/Portugal/Brasil, ecuación horizontal de Alemania, escueto-anglosajón de México. No asumas que es implica un solo layout — es-MX y es-ES/Brasil divergen entre sí en este eje.
4. Los símbolos de división y multiplicación son una preferencia de despliegue configurable por locale, no parte del contenido semántico del ítem. Guarda el operador como un nodo abstracto DIVIDE/MULTIPLY; renderízalo como ÷/: y ×/· según la configuración de locale/currículo.
5. El estilo de corchete de intervalo ((0,1) vs. ]0,1[) es una marca de renderizado por locale/currículo, más relevante para fr-FR (y posiblemente el francés belga), con de-DE y pt-PT ambiguos según el currículo — expónlo como una configuración de renderizado de contenido en lugar de una regla fija por idioma, y confírmalo con un consultor de currículo nativo antes de fijar un valor por defecto.
6. El nombrado de números grandes debe pasar por una función de número-a-palabras consciente del locale que distinga escala larga de corta, y específicamente NO debe asumir que la escala se correlaciona con el idioma: los locales de escala corta son {en-US, en-GB, pt-BR}; los locales de escala larga son {es-MX, es-ES, fr-FR, pt-PT, de-DE}. Un nombrador de números “pt” compartido nombrará mal los billones ya sea para Brasil o para Portugal.
7. Los separadores de lista/argumento en cadenas generadas deben cambiar a punto y coma (o a Intl.ListFormat) en los locales con decimal de coma para evitar chocar con la coma decimal — cualquier función que renderice una lista de números en línea (p. ej., “respuestas posibles: 2,5, 3,5, 4,5”) es activamente ambigua en fr/de/es-ES/pt sin esto.
8. Las cadenas de interfaz sensibles al conteo deben usar ICU MessageFormat/Intl.PluralRules con el conjunto completo de categorías CLDR por idioma, no una verificación n===1 — el francés/español/portugués enrutan el 0 a través de la categoría tipo one en algunas variantes de reglas, algo que un ayudante de pluralización centrado en inglés hará mal.
9. Reserva presupuesto de layout de interfaz para la expansión de texto en alemán (aproximadamente 20–35% más largo que el inglés en promedio, más en compuestos específicos) — valida los layouts con pseudolocalización o con cadenas alemanas largas reales, no solo con la línea base en inglés, especialmente en interfaces restringidas como botones, insignias y etiquetas de navegación móvil.
10. El contenido de secuencias de conteo y palabras numéricas para el grupo de edad más joven debe autorarse de forma nativa por idioma, no traducirse por máquina, porque la inversión alemana, el 70/80/90 vigesimal francés (más las variantes regionales septante/nonante), y los numerales adolescentes fusionados en español son diferencias estructurales en cómo se hablan los números, no solo sustituciones de vocabulario. Una traducción palabra por palabra de un ejercicio de conteo al estilo inglés o chino enseñará la forma hablada incorrecta.
11. La cobertura de voces TTS debe verificarse por locale antes de prometer lectura de números en audio, con atención explícita a si el proveedor de TTS elegido distingue es-MX de es-ES y pt-BR de pt-PT (esto queda sin resolver en este reporte — marcado como un ítem abierto, ver abajo) — construye una matriz de respaldo explícita (p. ej., pt-PT recae en una voz pt-BR con una limitación declarada) en lugar de dar la voz incorrecta a un locale en silencio.
12. Adopta Intl.NumberFormat / Intl.PluralRules / Intl.ListFormat como la capa de cumplimiento para todo el renderizado de número/texto sensible al locale, manteniendo un valor numérico canónico (p. ej., una cadena decimal, BigInt, o una representación de punto fijo — no una cadena formateada por locale) como la única fuente de verdad, localizando solo en el límite de renderizado y deslocalizando de inmediato en el límite de entrada.
13. Construye una tabla de “configuración de locale matemático” de primera clase (separador decimal, separador de agrupación, separador de lista, símbolo de división, símbolo de multiplicación, clave de layout de división larga, escala numérica, estilo de corchete de intervalo) indexada por un identificador de locale o de currículo, separada del i18n ordinario de cadenas de interfaz — las herramientas estándar de gettext/ICU manejan plurales e interpolación de cadenas pero no tienen un concepto nativo de “layout de división larga” o “escala numérica”, así que esto necesita una configuración personalizada, versionada y probable, junto a los archivos de traducción.
14. Las convenciones de despliegue de números mixtos vs. fracciones impropias difieren por país/currículo (mayor énfasis en números mixtos en los currículos de primaria de EE. UU./Reino Unido vs. un uso más consistente de fracciones impropias en algunas tradiciones europeas) — esto no se confirmó de forma independiente con una fuente citable en esta sesión y debe validarse directamente con consultores de currículo por locale antes de fijar un valor por defecto; trátese como un ítem abierto, no una convención establecida.
15. Cualquier función de entrada/salida de números hablados (entrada de respuesta por voz, ejercicios de números dictados) debe aceptar/producir ambas formas de palabra históricamente atestiguadas donde coexisten (p. ej., “dieciséis” vs. “diez y seis” en español) y manejar correctamente la inversión del orden hablado del alemán al mapear una palabra numérica dictada a su forma en dígitos — este es un problema de parseo distinto de la normalización de separador decimal escrito (implicación 2) y necesita su propia gramática consciente del locale, no una compartida.

Preguntas abiertas para el dueño del proyecto

• ¿Nos comprometemos a construir 4+ renderizadores distintos de división larga para el lanzamiento, o lanzamos uno solo (¿cuál?) con una advertencia documentada de “no auténtico para este currículo” para los demás locales?
• ¿El estilo de corchete de la notación de intervalos (paréntesis vs. corchete invertido) es un valor por defecto por locale, o una configuración ajustable por el usuario/maestro según la convención del libro de texto de cada salón?
• ¿Qué proveedor de TTS se usará realmente para leer números en voz alta, y tiene voces distintas confirmadas para es-MX/es-ES y pt-BR/pt-PT? (Sin resolver en este reporte — necesita una verificación directa con el proveedor.)
• ¿Debería el contenido de conteo para el grupo de edad más joven encargarse a consultores de pedagogía nativos por idioma en lugar de traducirse de un solo idioma fuente, dadas las diferencias estructurales (no léxicas) documentadas en §7?
• ¿Necesitamos granularidad de región de currículo por debajo del idioma (p. ej., fr-FR vs. fr-BE vs. fr-CH para septante/nonante; de-DE vs. de-CH) o es aceptable la granularidad a nivel idioma para la v1?
• ¿Debería la tabla de “configuración de locale matemático” (implicación 13) vivir en el sistema de autoría de contenido o en el código/configuración de la aplicación, y quién es responsable de actualizarla cuando se añade un locale nuevo?
• ¿Es el despliegue de números mixtos vs. fracciones impropias un valor por defecto por locale que estamos dispuestos a fijar, o necesita primero validación explícita de un consultor de currículo (ver implicación 14)?