Reglas de pluralización en diferentes idiomas: Guía para de…

Reglas de pluralización en diferentes idiomas: Guía para desarrolladores

Has lanzado una funcionalidad. Las traducciones están listas. Todo se ve perfecto en inglés. Entonces alguien reporta un bug: "La app dice '1 artículos en el carrito' y '5 artículo en el carrito'." Lo corriges con un operador ternario rápido. Seis meses después, un usuario en Polonia reporta que la app muestra texto gramaticalmente incorrecto en todas partes. No rompiste la pluralización — nunca la resolviste realmente.

La pluralización es uno de los problemas más subestimados en la internacionalización. La mayoría de los desarrolladores la tratan como un problema binario del inglés: singular versus plural. Pero los lenguajes naturales son mucho más complejos que eso, y en i18n de producción esa complejidad golpea duro. Esta guía explica cómo funciona realmente la pluralización entre idiomas, cómo implementarla correctamente y cómo evitar los errores que se cuelan en cada revisión de código.

Si eres nuevo en los conceptos de internacionalización de forma más amplia, la guía sobre localización e internacionalización ofrece una base útil antes de adentrarse en la mecánica de pluralización específica de cada idioma.

Por qué la pluralización importa más de lo que crees

Aquí hay un patrón común en las bases de código:

const label = count === 1 ? 'artículo' : 'artículos';

Esto funciona para el inglés. Para exactamente dos idiomas: inglés y un puñado de similares. En el momento en que lo despliegas en turco, árabe, ruso o polaco, este enfoque produce sinsentidos — o peor, texto sutilmente incorrecto de formas que resultan irrespetuosas para los hablantes nativos.

Los errores de pluralización en producción tienen consecuencias reales:

Erosión de la confianza: Los hablantes nativos reconocen de inmediato la gramática incorrecta. Indica que el producto no fue construido para ellos.
Riesgo legal: En algunas regiones, las expresiones de cantidad en contratos, facturas o textos de cumplimiento deben ser gramaticalmente correctas.
Fallos de accesibilidad: Los lectores de pantalla y las herramientas de asistencia dependen de texto gramaticalmente correcto.

La causa raíz es casi siempre la misma: los desarrolladores codifican de forma fija la lógica plural del inglés, y luego los traductores reciben una cadena sin contexto sobre qué forma usar.

Los plurales en inglés: Engañosamente simples

El inglés tiene dos formas plurales: singular (1) y plural (todo lo demás). Esto se mapea limpiamente a una expresión ternaria, que es por qué los desarrolladores lo usan por defecto.

// Inglés: dos formas, singular y plural
`${count} ${count === 1 ? 'archivo' : 'archivos'} subido(s)`

Pero incluso en inglés, esto se complica con casos límite:

Cero: "0 archivos" se lee naturalmente, pero algunas interfaces prefieren "Sin archivos". Esta es una decisión de diseño, no de traducción — pero aún requiere soporte de forma plural.
Fracciones: "1.5 archivos" es gramaticalmente ambiguo. El inglés típicamente usa el plural para valores no enteros, pero esto varía según el dominio.
Sustantivos irregulares: "1 persona" / "2 personas", "1 niño" / "2 niños". Estos no se manejan con reglas de sufijos simples.

El inglés se siente simple porque lo es, relativamente hablando. En el momento en que lo abandonas, la complejidad escala dramáticamente.

Cómo otros idiomas manejan los plurales

Árabe: Seis formas

El árabe tiene seis formas plurales gramaticalmente distintas según el número:

Forma	Números
zero	0
one	1
two	2
few	3–10
many	11–99
other	100+ (y decimales)

Cada forma requiere una palabra o sufijo diferente. La cadena "Tienes X mensajes" necesita seis traducciones en árabe, no dos. Enviar solo singular y plural a un traductor árabe es pedirle que adivine — y no puede, porque la estructura del mensaje difiere para cada forma.

Ruso y polaco: De tres a cuatro formas con reglas complejas

El ruso usa tres formas: singular (1), few (2–4 y números que terminan en 2–4, excepto 12–14) y many (todo lo demás).

La regla para el ruso no es trivial:

n % 10 === 1 && n % 100 !== 11  → singular
n % 10 >= 2 && n % 10 <= 4 && (n % 100 < 10 || n % 100 >= 20) → few
todo lo demás → many

Así que: "21 файл" (singular), "22 файла" (few), "25 файлов" (many), "11 файлов" (many — no singular, porque 11 es una excepción).

El polaco añade mayor complejidad con cuatro formas y límites ligeramente diferentes. Si lo haces mal, un usuario ruso o polaco lo nota de inmediato. Estos no son casos límite oscuros — son números que aparecen en interfaces de usuario cotidianas.

Japonés, chino, coreano: Sin plurales en absoluto

Estos idiomas no distinguen gramaticalmente entre singular y plural. "1 archivo" y "100 archivos" usan la misma forma nominal. En cambio, la cantidad se expresa a través de numerales, contadores (clasificadores) o contexto.

Esto significa:

No debes enviar formas plurales a los traductores para estos idiomas — les estás pidiendo que traduzcan distinciones que no existen.
El número todavía se muestra, pero no modifica el sustantivo.
El manejo incorrecto de plurales aquí generalmente se manifiesta como traductores que duplican la forma "other", lo cual es técnicamente aceptable pero puede producir frases redundantes o poco naturales.

Otros casos destacables

Lenguas eslavas en general (checo, eslovaco, croata): De tres a cuatro formas, reglas de módulo complejas.
Galés: Seis formas con límites muy irregulares.
Gaélico (escocés e irlandés): Formas que se dividen en 1, 2, 3–10, 11–19 y 20+.
Hebreo: Formas distintas para singular, dual (exactamente 2) y plural.

El estándar de reglas plurales CLDR

El Repositorio de Datos Comunes de Localización Unicode (CLDR) define reglas plurales para todos los idiomas principales. Estas son las reglas canónicas utilizadas por navegadores, sistemas operativos y bibliotecas i18n. El CLDR categoriza las formas plurales en seis categorías nombradas:

zero
one
two
few
many
other

Cada idioma usa algún subconjunto de estas. El inglés usa one y other. El árabe usa las seis. El japonés usa solo other.

Estas reglas están disponibles en forma legible por máquina y ya están incorporadas en la mayoría de las bibliotecas i18n maduras. No necesitas implementar las matemáticas tú mismo. Sí necesitas entender que estas categorías existen y que tu flujo de trabajo de traducción debe tener en cuenta todas las formas que un idioma dado requiere.

ICU MessageFormat: La abstracción correcta

ICU MessageFormat es el estándar más ampliamente soportado para expresar pluralización en cadenas de traducción. Incorpora la lógica plural dentro del mensaje mismo, para que los traductores puedan manejar cada forma de forma independiente.

La sintaxis para inglés:

{count, plural,
  one {# archivo subido}
  other {# archivos subidos}
}

Para ruso (tal como lo proporciona un traductor que conoce el idioma):

{count, plural,
  one {Загружен # файл}
  few {Загружено # файла}
  many {Загружено # файлов}
  other {Загружено # файлов}
}

El # se reemplaza por el número real. La biblioteca evalúa la regla plural para el locale activo y elige la forma correcta.

Este enfoque tiene ventajas críticas sobre la concatenación de cadenas:

Cada forma es una oración completa, por lo que los traductores tienen contexto gramatical completo.
Sin ensamblaje de cadenas en tiempo de ejecución — el mensaje se resuelve a una cadena final antes de mostrarse.
Formas apropiadas para cada idioma — los traductores proporcionan exactamente las formas que su idioma necesita.
Soporte de herramientas — linters, herramientas de extracción y plataformas de traducción entienden este formato.

Implementando pluralización con i18next

i18next es una de las bibliotecas i18n más utilizadas en el ecosistema JavaScript, y maneja las reglas plurales CLDR de forma nativa.

Configuración básica

import i18next from 'i18next';

i18next.init({
  lng: 'en',
  resources: {
    en: {
      translation: {
        file_count: '{{count}} archivo',
        file_count_other: '{{count}} archivos',
      },
    },
  },
});

i18next usa una convención de sufijo de clave: key para la forma singular, key_other para el plural por defecto y key_zero, key_one, key_two, key_few, key_many para formas CLDR adicionales. Pasas count como variable de interpolación, y la biblioteca selecciona la clave correcta automáticamente.

i18next.t('file_count', { count: 1 });   // "1 archivo"
i18next.t('file_count', { count: 5 });   // "5 archivos"

Integración con React

Con react-i18next:

import { useTranslation } from 'react-i18next';

function FileCount({ count }: { count: number }) {
  const { t } = useTranslation();
  return <span>{t('file_count', { count })}</span>;
}

Para configuraciones /i18n/react, este es el patrón recomendado. La variable count impulsa tanto la interpolación (mostrar el número) como la selección de forma plural.

Manejo de múltiples formas CLDR

Para ruso, tu archivo de traducción necesita todas las formas requeridas:

{
  "file_count_one": "{{count}} файл",
  "file_count_few": "{{count}} файла",
  "file_count_many": "{{count}} файлов",
  "file_count_other": "{{count}} файлов"
}

i18next aplica la regla CLDR correcta para el locale y elige la clave correcta. La evaluación de reglas está incorporada — no escribes la lógica de módulo tú mismo.

Next.js con next-i18next

Para aplicaciones /i18n/nextjs que usan next-i18next, el patrón es el mismo pero las traducciones viven en public/locales/{lng}/{ns}.json:

// public/locales/ru/common.json
{
  "file_count_one": "{{count}} файл",
  "file_count_few": "{{count}} файла",
  "file_count_many": "{{count}} файлов",
  "file_count_other": "{{count}} файлов"
}

import { useTranslation } from 'next-i18next';

export function FileCount({ count }: { count: number }) {
  const { t } = useTranslation('common');
  return <p>{t('file_count', { count })}</p>;
}

Errores comunes

1. Nombre de variable incorrecto

i18next usa count específicamente para activar la selección de forma plural. Usar cualquier otro nombre de variable omite completamente la lógica plural:

// MAL — la selección plural no se activará
t('file_count', { number: 5 });

// BIEN
t('file_count', { count: 5 });

Esto es un fallo silencioso. Se usa la forma de respaldo (_other), por lo que el inglés puede parecer correcto mientras otros idiomas fallan silenciosamente.

2. Formas plurales faltantes para el locale objetivo

Si defines solo key y key_other para un locale ruso, la biblioteca vuelve a key_other para todas las formas. Los usuarios rusos reciben texto gramaticalmente incorrecto y no hay ningún error en la consola. Este es el bug de pluralización más común en el software entregado.

La solución es requerir todas las formas CLDR para cada locale antes de entregar. Automatiza esta verificación — no confíes en la revisión manual.

3. Concatenación de cadenas en lugar de claves plurales

// MAL
const message = t('you_have') + ' ' + count + ' ' + t('messages');

// BIEN — el recuento y las palabras circundantes son una unidad traducible
t('you_have_messages', { count });

La concatenación hace estructuralmente imposible manejar idiomas donde el orden de palabras, la forma nominal o la concordancia verbal cambian con el recuento. La frase completa que contiene el recuento debe ser una única clave de traducción.

4. Confundir ordinales con plurales cardinales

Los números ordinales ("1.°", "2.°", "3.°") siguen reglas completamente diferentes a los plurales cardinales. No los confundas. i18next tiene soporte ordinal separado mediante la opción ordinal: true:

t('position', { count: 1, ordinal: true });  // "1.er lugar"
t('position', { count: 2, ordinal: true });  // "2.° lugar"

Las reglas ordinales también son específicas del locale — el francés, por ejemplo, usa "1er" para el primero y luego el mismo sufijo para todos los ordinales posteriores.

5. Tratar el cero como una forma plural especial

Algunos diseños requieren "Sin archivos" en lugar de "0 archivos". Esto no es una forma plural — es una decisión de UI. Manéjalo explícitamente en el código antes de llamar a la función de traducción, o usa una clave de traducción separada:

const key = count === 0 ? 'no_files' : 'file_count';
t(key, { count });

No confíes en la forma CLDR zero para decisiones de texto de UI. La forma zero existe para idiomas que distinguen gramaticalmente el cero de otros valores, no como un gancho de diseño.

Probar las traducciones plurales

El manejo de plurales está notoriamente poco probado. Para una visión más amplia de cómo estructurar tu proceso de calidad i18n, la guía sobre herramientas de prueba i18n y estrategias de automatización cubre herramientas que se pueden integrar junto con estos patrones.

Pruebas de valores límite

Prueba cada valor límite para los locales que despliegas:

const testCounts = [0, 1, 2, 3, 4, 5, 11, 12, 21, 22, 100, 101];

for (const count of testCounts) {
  console.log(`${count}: ${t('file_count', { count })}`);
}

Para ruso específicamente: 1, 2, 5, 11, 12, 21, 22, 25, 100, 101, 111, 121.

Pruebas de instantánea para cada locale

describe('pluralización file_count', () => {
  it.each([
    ['en', 1, '1 file'],
    ['en', 5, '5 files'],
    ['ru', 1, '1 файл'],
    ['ru', 2, '2 файла'],
    ['ru', 5, '5 файлов'],
    ['ru', 11, '11 файлов'],
    ['ru', 21, '21 файл'],
    ['ar', 1, '1 ملف'],
    ['ar', 3, '3 ملفات'],
  ])('locale %s, count %d → %s', (lng, count, expected) => {
    i18next.changeLanguage(lng);
    expect(i18next.t('file_count', { count })).toBe(expected);
  });
});

Esto captura formas faltantes, límites CLDR incorrectos y errores del traductor antes de que lleguen a los usuarios.

Lint para formas faltantes

Escribe un script que lea las claves de tu locale fuente, identifique todas las claves plurales (las que terminan en _other) y luego verifique cada locale objetivo para las formas CLDR requeridas por ese locale. Falla la CI si faltan formas. Esto previene completamente la clase de bugs de fallback silencioso.

Donde la seguridad de tipos cambia el juego

Una debilidad de i18n basada en cadenas de claves es que nada impone el uso correcto en el sitio de llamada. Puedes pasar number en lugar de count, omitir el count por completo, o referenciar una clave que no existe — y todos estos fallan silenciosamente en tiempo de ejecución.

Las herramientas i18n con seguridad de tipos generan tipos TypeScript a partir de tus claves de traducción, para que el compilador detecte:

Variables de interpolación requeridas faltantes
Usar el nombre de variable incorrecto (number vs count)
Referenciar claves inexistentes

Better i18n construye sobre este patrón con SDKs que entienden tu esquema de traducción y hacen cumplir la completitud plural en tiempo de publicación. Cuando agregas una nueva clave plural, el SDK genera tipos actualizados — y cualquier sitio de llamada que no suministre la variable count requerida se convierte en un error de tipo. Para equipos que gestionan docenas de locales con cientos de claves, esto captura toda una clase de bugs de pluralización antes de la revisión de código.

Las características de la plataforma que más importan para la pluralización son: completitud de formas obligatoria (todas las formas CLDR requeridas deben estar presentes antes de publicar), traducción con IA que entiende el contexto ("esto es un recuento de archivos, usa la forma plural apropiada"), y aplicación de glosario para que los sustantivos específicos del dominio se inflexionen de manera consistente.

La corrección de pluralización también está profundamente relacionada con un flujo de trabajo bien estructurado de traducción y localización de sitios web — cuando las formas plurales se recopilan y revisan como parte del mismo proceso que el resto de la traducción, es mucho menos probable que se cuelen incompletas.

Resumen práctico

La pluralización correcta requiere:

Usa ICU MessageFormat o una biblioteca que implemente las reglas CLDR. No escribas tu propia lógica plural.
Siempre usa count como variable de interpolación en i18next. Otros nombres omiten la selección plural.
Proporciona todas las formas CLDR para cada locale. Verifica qué formas requiere un idioma antes de enviar cadenas a los traductores.
Nunca concatenes cadenas con recuentos. La frase completa es una clave de traducción.
Prueba los valores límite para cada locale. Especialmente ruso, polaco, árabe y otros idiomas con reglas complejas.
Impón la completitud de formas en CI. Las formas plurales faltantes causan fallbacks silenciosos que son invisibles en las pruebas en inglés.
Distingue ordinales de cardinales. Siguen reglas diferentes y necesitan manejo separado.

Las herramientas existen para hacerlo bien. Las reglas CLDR están estandarizadas. Las bibliotecas las implementan. El modo de fallo en la mayoría de las bases de código no es técnico — es asumir que la lógica plural del inglés se generaliza, y no construir el flujo de trabajo para detectar cuando no lo hace.

Lleva tu app al mundo con better-i18n

better-i18n combina traducciones impulsadas por IA, flujos de trabajo nativos de git y distribución CDN global en una plataforma centrada en el desarrollador. Deja de gestionar hojas de cálculo y empieza a lanzar en todos los idiomas.

Comenzar gratis → · Explorar características · Leer la documentación

Reglas de pluralización en diferentes idiomas: Guía para desarrolladores