Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Copy Source | Copy HTML
- <?php
- /**
* Функция склонения числительных в русском языке
*
* @param int $number Число которое нужно просклонять
* @param array $titles Массив слов для склонения
* @return string
**/
- function pluralForm($number, $titles)
- {
- $cases = array (2, , 1, 1, 1, 2);
- return number_format($number, , ',', ' ' ) . " " . $titles[ ($number%100>4 && $number%100<20)? 2 : $cases[min($number%10, 5)] ];
- }
- ?>
пользоваться:
Copy Source | Copy HTML
- <?= $app->pluralForm($filmStats['count'], array('фильм', 'фильма', 'фильмов'))?>
У вас в описании функции указано, что это только для русского языка. В статье видно, что для разных языков правила формирования могут быть разными
Как видно, наиболее сложным языком из поддерживаемых в данном аспекте является
арабский с его 6 вариантами :)
В статье сказано, что самым сложным является арабский, а пример форм дан для русского слова «комментарий». Я вообще не рублю в арабском, но быстро просканировал статью www.iaas.msu.ru/res/lomo06/lingvo/berzigiyarova.htm и думаю, что надо бы всё же составить пример для этого языка как для самого сложного варианта. Да и для других не помешало бы, для общего представления.
немного подредактировал статью + вставил подсветку синтаксиса.
зачем для русского, в котором всего 3 множественных формы, определять 6 строк?
Этот пример — для 20+ языков.
Например, для японского нужна только одна форма, потому что у них форма числительного от количества не зависит.
В английском две формы: для единственного (one comment) и множественного (some comments).
Во французском тоже две, но правила подстановки отличаются.
В русском три формы: заканчивающиеся на 1, но не 11 (один комментарий), заканчивающиеся на 2,3,4 (два комментария) и остальные (пять комментариев)
В чешском тоже три, но правила подстановки другие.
В арабском — 6 форм, но я, к сожалению, их не знаю. Вот если бы кто-нибудь составил пример для слова «комментарий», мне и остальным было намного понятнее.
Например, для японского нужна только одна форма, потому что у них форма числительного от количества не зависит.
В английском две формы: для единственного (one comment) и множественного (some comments).
Во французском тоже две, но правила подстановки отличаются.
В русском три формы: заканчивающиеся на 1, но не 11 (один комментарий), заканчивающиеся на 2,3,4 (два комментария) и остальные (пять комментариев)
В чешском тоже три, но правила подстановки другие.
В арабском — 6 форм, но я, к сожалению, их не знаю. Вот если бы кто-нибудь составил пример для слова «комментарий», мне и остальным было намного понятнее.
Использование максимального кол-ва языковых «ключей» для всех языков продиктовано необходимостью поддержки языков в актуальном состоянии.
Процесс перевода в проекте выглядит следующим образом:
* фраза добавляется в английский и русский, так как разработчики знают эти два языка.
* запускается утилита, добавляющая те же самые фразы во все остальные языки (например, в арабский добавляется копия фраз из английского)
* переводчики через публичный интерфейс редактируют ещё не переведённые фразы, используя какой-нибудь язык в качестве «источника»
Если количество вариантов фразы в разных языках будет разным, то необходимо усложнять утилиту и интерфейс для переводчиков.
При этом в проекте используются PHP accelerator, так что потери производительности из-за лишних ключей достаточно малы.
Естественно, в случае другого процесса перевода такое может и не понадобиться.
Надеюсь, ответил на Ваш вопрос.
Процесс перевода в проекте выглядит следующим образом:
* фраза добавляется в английский и русский, так как разработчики знают эти два языка.
* запускается утилита, добавляющая те же самые фразы во все остальные языки (например, в арабский добавляется копия фраз из английского)
* переводчики через публичный интерфейс редактируют ещё не переведённые фразы, используя какой-нибудь язык в качестве «источника»
Если количество вариантов фразы в разных языках будет разным, то необходимо усложнять утилиту и интерфейс для переводчиков.
При этом в проекте используются PHP accelerator, так что потери производительности из-за лишних ключей достаточно малы.
Естественно, в случае другого процесса перевода такое может и не понадобиться.
Надеюсь, ответил на Ваш вопрос.
какой бред.
я писал сам и инструменты для i18n/l10n и интерфейсы для редактирования ресурсов. никаких там разумных усложнений нет, акститесь.
я писал сам и инструменты для i18n/l10n и интерфейсы для редактирования ресурсов. никаких там разумных усложнений нет, акститесь.
Интересно.
Я правильно понимаю, что в Ваших инструментах и интерфейсах редактирования Вы смогли уйти от данной проблемы?
Могли бы Вы привести пример такого или другого интерфейса для перевода, который удобнее по Вашему мнению и лишён описанных недостатков?
Я правильно понимаю, что в Ваших инструментах и интерфейсах редактирования Вы смогли уйти от данной проблемы?
Могли бы Вы привести пример такого или другого интерфейса для перевода, который удобнее по Вашему мнению и лишён описанных недостатков?
в инструменте проблемы не существует вообще.
а в интерфейсе переводчика достаточно вывести в иностранном языке первой формы. этого достаточно, потому как:
1. одной формы достаточно, чтобы понять, что значит фраза
2. «используя какой-нибудь язык в качестве «источника»» // в разных языках разные словоформы не релевантны — поэтому их все выводить смысла нет.
т.е. мой интерфейс выглядел как-то так:
<имя переменной> (фактически уникальный ключ, по которому осуществлялся доступ в коде и шаблонах)
<строковый литерал первой словоформы дефолтного языка приложения> (обычно en)
0) [____________]
а в интерфейсе переводчика достаточно вывести в иностранном языке первой формы. этого достаточно, потому как:
1. одной формы достаточно, чтобы понять, что значит фраза
2. «используя какой-нибудь язык в качестве «источника»» // в разных языках разные словоформы не релевантны — поэтому их все выводить смысла нет.
т.е. мой интерфейс выглядел как-то так:
<имя переменной> (фактически уникальный ключ, по которому осуществлялся доступ в коде и шаблонах)
<строковый литерал первой словоформы дефолтного языка приложения> (обычно en)
0) [____________]
1) [____________]
…
N) [____________]
^^^^ поля перевода соответствующих словоформ редактируемого языка
ps: как-то странно себя повело поле комменатриев, отпостило коммент по нажатию на бэкспейс, хмхм
…
N) [____________]
^^^^ поля перевода соответствующих словоформ редактируемого языка
ps: как-то странно себя повело поле комменатриев, отпостило коммент по нажатию на бэкспейс, хмхм
То есть интерфейс перевода знал (либо это было описано в файле) кол-во форм для конкретного языка? Или позволял ввести необходимое кол-во вариантов фраз?
А каким образом переводчик понимал что именно эту фразу нужно перевести в нескольких вариантах, а соседнюю фразу нужно просто перевести — варианты множественных форм выделялись или редактировались отдельно?
Кстати, нет ли ссылки на программу или веб-интерфейс для переводчика? Хотелось бы посмотреть в живую.
А каким образом переводчик понимал что именно эту фразу нужно перевести в нескольких вариантах, а соседнюю фразу нужно просто перевести — варианты множественных форм выделялись или редактировались отдельно?
Кстати, нет ли ссылки на программу или веб-интерфейс для переводчика? Хотелось бы посмотреть в живую.
конечно интерфейс перевода знал число словоформ. он спрашивал их у класса i18n, у которого были алгоритмы и прочая полезная инфа.
А число необходимых словоформ легко определялись (конкретно у меня) по наличию плейсхолдеров. Если плейсхолдер во фразе есть, то очевидно, что по его значению будет считаться форма.
примерно:
[comments_count]
0 = "? comment"
1 = "? comments"
Переводчику выводится литерал «0 comment», очевидно что нужно переводить с учётом всех форм.
А вживую — всё работает так как я описал выше, правда без вёрстки и какого либо намёка на дизайн. Ничего нового сверх нарисованной выше схемы формы там нет.
А число необходимых словоформ легко определялись (конкретно у меня) по наличию плейсхолдеров. Если плейсхолдер во фразе есть, то очевидно, что по его значению будет считаться форма.
примерно:
[comments_count]
0 = "? comment"
1 = "? comments"
Переводчику выводится литерал «0 comment», очевидно что нужно переводить с учётом всех форм.
А вживую — всё работает так как я описал выше, правда без вёрстки и какого либо намёка на дизайн. Ничего нового сверх нарисованной выше схемы формы там нет.
Текущая версия I18N-0.8.6 (http://pear.php.net/package/I18N) поддерживает меньше языков чем нужно + я к сожалению вообще не нашёл в нем возможности по выводу множественных форм. Вы его имели ввиду? Или я плохо смотрел?
Я подумаю над Вашим вариантом, т.к. потенциально он позволит отказаться от знания алгоритма переводчиком. Больше значительных преимуществ для проекта я не вижу.
Спасибо за информацию.
Я подумаю над Вашим вариантом, т.к. потенциально он позволит отказаться от знания алгоритма переводчиком. Больше значительных преимуществ для проекта я не вижу.
Спасибо за информацию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вариант PHP кода для вывода строки в множественном числе