Справочник по формам множественного числа в KDE

С 20 июля 2010 года русский перевод KDE (стабильной и нестабильной ветвей) переведен на новую формулу работы с формами множественного числа (тождественную той, которая используется в сербском языке):

Plural-Forms: nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n

На этой странице вы можете найти ответы на самые распространённые вопросы, связанные с переходом.

Зачем?

Каковы причины перехода?

Рассмотрим пример. Пусть надо перевести на русский такую комбинацию сообщений (digiKam):

msgid "You have edited the image caption. 
msgid_plural "You have edited the captions of %1 images"

Предыдущая формула записи форм множественного числа предоставляла возможность использовать для перевода три формы:

0: для 1, 21, 31, 41 ... подписи 
1: для 2, 3, 4, 22, 23 ... подписей 
2: для 5, 6, 7 ... подписей. 

Типичной ошибкой, которую совершают как опытные, так и начинающие переводчки, является такой перевод:

msgstr [0] "Вы изменили подпись к снимку."
msgstr [1] "Вы изменили подписи к %1 снимкам." 
msgstr [2] "Вы изменили подписи к %1 снимкам."

Простая проверка msgfmt -v -c digikam.po показывает, что такой перевод является некорректным с точки зрения gettext. Почему?

Вы наверно уже догадались: нулевая форма описывает не один, а бесконечно много вариантов. У нас же описан пока лишь перевод для единственного числа. Для исправления этого недостатка приходилось делать так:

msgstr [0] "Вы изменили подпись к %1 снимку."
msgstr [1] "Вы изменили подписи к %1 снимкам." 
msgstr [2] "Вы изменили подписи к %1 снимкам."

Выглядит неуклюже (пользователю будет показана чрезмерная информация в случае 1 подписи), но работает.

Немного видоизменения пример:

msgid "You have edited the image caption. 
msgid_plural "You have edited the captions of images"

Теперь любой перевод по старой формуле будет иметь ложные варианты:

msgstr [0] "Вы изменили подпись к снимку."
msgstr [1] "Вы изменили подписи к снимкам." 
msgstr [2] "Вы изменили подписи к снимкам."

Ошибка: подписей может быть 21, а это отнюдь не «подпись».

msgstr [0] "Вы изменили подписи к снимкам."
msgstr [1] "Вы изменили подписи к снимкам." 
msgstr [2] "Вы изменили подписи к снимкам."

Ошибка: подписей может быть 1, а это отнюдь не «подписи».

msgstr [0] "Вы изменили подпись к %1 снимку."
msgstr [1] "Вы изменили подписи к %1 снимкам." 
msgstr [2] "Вы изменили подписи к %1 снимкам."

Ошибка: формально работает, но не проходит проверку msgfmt.

Новая формула лишена недостатков предыдущей. С ней мы можем чётко отмежевать единственное число от всех других случаев:

msgstr [0] "Вы изменили подписи к %1 снимку."
msgstr [1] "Вы изменили подписи к %1 снимкам." 
msgstr [2] "Вы изменили подписи к %1 снимкам."
msgstr [3] "Вы изменили подпись к снимку."

msgstr [0] "Вы изменили подписи к снимкам."
msgstr [1] "Вы изменили подписи к снимкам." 
msgstr [2] "Вы изменили подписи к снимкам."
msgstr [3] "Вы изменили подпись к снимку."

Почему такой порядок форм? Не было бы логичнее использовать единственное число для формы [0]?

Дело в том, что в редакторах (Virtaal) и некоторых системах перевода (Launchpad/Rosetta) количество форм жёстко зашито в код. Таким образом, четвёртая (новая форма) будет обрезана при импортировании без каких-либо предупреждений. Если переставить форму [3] на место формы [0], мы получим результат, который, как уже упоминалось выше, не проходит проверки утилитами gettext и сценариями Rosetta.

Как перейти на новую формулу?

Часлав Илич (координатор сербской команды KDE) предоставил скрипт, который работает на основе оболочки обработки переводов KDE Pology:

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

import fallback_import_paths
import os
import sys

from pology.file.catalog import Catalog
from pology.misc.fsops import collect_catalogs
from pology.misc.report import report, error

cmd = os.path.basename(sys.argv[0])
args = sys.argv[1:]
if len(args) != 3:
    error("Usage: %(cmd)s PATH PLURALFORMS COPYMAP" % dict(cmd=cmd))
path = args.pop(0)
newplhead = args.pop(0)
copyspec = args.pop(0)

# Process form mapping.
srcforms = set()
dstforms = set()
copymap = {}
for spec1 in copyspec.split(","):
    try:
        sform, dform = map(int, spec1.split(">"))
    except:
        error("Malformed copy map '%(map)s'." % dict(map=copyspec))
    copymap[sform] = dform
    srcforms.add(sform)
    dstforms.add(dform)
if max(srcforms) + 1 != len(srcforms):
    error("Gaps in source forms.")
if max(dstforms) + 1 != len(dstforms):
    error("Gaps in destination forms.")
copyord = [0] * len(dstforms)
for sform, dform in copymap.items():
    copyord[dform] = sform

# Convert catalogs.
for popath in collect_catalogs(path):
    cat = Catalog(popath)
    cat.header.replace_field_value(u"Plural-Forms", unicode(newplhead))
    for msg in cat:
        if msg.msgid_plural is not None:
            msg.msgstr[:] = [msg.msgstr[x] for x in copyord]
    if cat.sync():
        report(cat.filename)

Чтобы перевести ваши переводы на новую формулу, загрузите Pology, сохраните скрипт в подкаталог scripts и отдайте команду:

./modplforms.py /шлях/до/каталогу/перекладів  'nplurals=4; plural=n==1 ? 3 : n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;0>0,1>1,2>2,0>3'

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

Что дальше?

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

Все остальные дистрибутивы, которые используют коды, предлагаемые для использования непосредственно командой KDE, смогут воспользоваться преимуществами нового формата.

Transifex, poEdit и Lokalize понимают новую формулу без проблем.

Безусловно, команда переводчиков KDE будет рада помочь всем, у кого возникнут вопросы, касающиеся новой формулы, поскольку, очевидно, проблемы, приведшие к переходу, существуют во многих рабочих средах (GNOME, XFCE...) и отдельных программах (Inkscape, Audacity...).