«21 записей» в интерфейсе: как задать формы числа

Исправление «21 записей» начинается с выбора формы целого сообщения по числу и локали. Для количественных русских сообщений нужны разные категории, а не условие «один или много». Intl.PluralRules помогает выбрать категорию, но не переводит слово и не определяет контекст фразы. Текст каждой формы должен быть подготовлен и проверен редактором.

Последняя цифра не описывает всё правило

Счётчик может правильно показать «1 запись» и ошибиться на 11. Или пройти небольшой тест и сломаться на 21. Если разработчик добавляет исключения по одному найденному случаю, правила быстро расходятся между списком, уведомлением и отчётом. Проблема находится в модели сообщения, а не в конкретном окончании, которое нужно заменить на экране.

В таблице CLDR для русского языка количественные категории различают, в частности, значения с последней единицей и исключением 11, группы 2–4 с исключением 12–14 и дробные формы. Полное правило учитывает несколько свойств числа. Копирование английской пары one/other не заменяет эти условия.

Категория API — ещё не готовая русская фраза

MDN описывает Intl.PluralRules как механизм выбора языковой категории с учётом локали, типа правила и параметров форматирования. Результат вроде one или few — метка для дальнейшего выбора текста. Она не содержит существительное, падеж или контекст действия.

Для разработки русского интерфейса храните связанные варианты одного сообщения вместе. Например, сообщение о найденных записях должно иметь согласованные формы целиком, включая слово «найдено» либо другую выбранную конструкцию. Не собирайте его из числа, одного окончания и произвольного глагола, если эта сборка не проверена для всех вариантов.

Матрица проверки счётчиков

Значения ниже проверены локально через Intl.PluralRules с локалью ru и типом cardinal в текущем Node/ICU, а категории сверены с CLDR. Это учебные проверки, не статистика сервиса. Для целых записей и дробной длительности используются разные сообщения: дробное количество записей не предлагается как бизнес-модель.

Результат этого локального прогона сохранён вместе с версией среды. При внедрении повторите набор в фактическом окружении проекта, особенно если категории выбираются и на сервере, и в браузере. Проверка одной машины подтверждает свой результат, а не совместимость всех версий и платформ.

Форматирование дроби влияет на проверку

Сначала договоритесь, что увидит человек: округлённое целое, дробь с переменной точностью или всегда один знак после запятой. Выбор категории и форматирование числа должны использовать согласованные параметры. Иначе интерфейс может показать округлённое целое рядом с формой, выбранной для другого представления.

В проверенном runtime значение 1,0 без принудительного десятичного знака выбирает one, как 1. При минимальном и максимальном количестве дробных знаков, равном одному, выбор для отображения 1,0 даёт other. Это пример влияния параметров, а не утверждение, что любой исходный текст «1,0» во всех API автоматически сохранит отдельный вид. Его нужно проверять в своём формате данных.

Для дискретного счётчика заранее определите, допустимы ли дроби вообще. Ошибка источника не должна превращаться в грамматически красивое, но бессмысленное сообщение. Отсутствующее значение тоже не равно нулю: «данные ещё не получены» отличается от «нет записей». Это решение о состоянии интерфейса принимают до языковой формы.

Целое сообщение в каталоге переводов

Используйте возможности выбранной библиотеки, например plural-сообщения в поддерживаемом ею формате ICU, если он предусмотрен в проекте. Не смешивайте синтаксис разных библиотек по памяти. Разработчик должен проверить поддержку формата, а редактор — все получающиеся варианты. Для каждого сообщения сохраните контекст и смысл параметра.

Если ноль требует отдельного продуктового текста, можно предусмотреть «Записей пока нет» как явный вариант состояния. Не называйте это доказательством, что русская грамматическая категория называется zero. Грамматический выбор, точное совпадение с заданным значением и сообщение о пустом результате могут быть разными механизмами.

Также разделите количество и порядок. «Найдено несколько объектов» и подпись порядкового места используют разные правила. Варианты текста для одной задачи нельзя автоматически применять к другой. Для мобильного приложения и веб-версии стоит передавать общий смысл сообщения, а не независимые наборы упрощённых окончаний.

Как проверить результат редактору и разработчику

1. Для каждого счётчика определите, что считается и какие значения допустимы. Отдельно опишите неизвестность и пустой результат.
2. Выберите локаль и количественный либо порядковый тип правила. Проверьте реальную библиотеку, её формат сообщений и используемые параметры.
3. Подготовьте целые фразы для нужных категорий. Укажите контекст, чтобы перевод не подбирался по одному существительному.
4. Выполните набор с 0, 1, 2, 5, 11–14, 21, 22, 25 и составными значениями. Для дробных величин добавьте собственные допустимые примеры.
5. Сопоставьте выбранную категорию, отображённое число и конечный текст. Проверяйте не только выход API.
6. Повторите сообщения в списке, письме, выгрузке и мобильном интерфейсе, где они применяются. Изменение одного канала не должно оставлять прежнюю ошибку в другом.

Что передать в реализацию

Для автоматизации документов и уведомлений подготовьте не таблицу окончаний, а перечень сообщений с контекстами и ожидаемыми примерами. Отдельно перечислите среды, где они формируются. Если сервер уже передаёт готовую строку, браузер не должен заново применять к ней свой случайный механизм выбора.

Принятый результат — правильная фраза при каждом допустимом состоянии данных, а не только вызов подходящего API. Сохраните учебный набор и исходный каталог сообщений рядом с правилами проекта. Тогда новое существительное, дополнительный язык или изменённая точность числа можно проверить до выпуска интерфейса.