Комментарии 12
Покажит, пожалуйста, пример использования сообщений (с этими длинющими ID) посреди другого кода. Или скриншот React-компонента это и есть?
Со стороны перевода мне интересно, как дела у инструментария с видоизменившимися и похожими текстами. Есть ли где контекстуальные подсказки типа "вот этих текстов не стало", пока предстают к переводу с нуля новые тексты? Есть ли более общее "данная строка похожа на вот эту, которая уже переведена". Потому что иначе соблюдать стиль перевода будет сложно (а выводить абсолютно всё в глоссарий - прошлый век).
Ну и смежная тема -- переиспользование и согласование переводов между проектами. Хотя у Яндекса, как компании, может быть условный монорепозиторий для конечных пользователей CAT инструмента.
По поводу первого вопроса о "показе примера использования сообщений (с этими длинными ID) посреди другого кода", вы правы: скриншот React-компонента в статье — это и есть пример.
Относительно вопроса о контекстуальных подсказках вроде "вот этих текстов не стало" или "данная строка похожа на вот эту, которая уже переведена", в самом проекте такого инструмента у нас нет. Но он и не требуется, поскольку подобный функционал внедрен во многих CAT tools (в том числе в тот, который мы используем) через так называемую память переводов.
Что касается последнего вопроса о переиспользовании и согласовании переводов между проектами, то тут ответ такой. Мы рекомендуем в таких проектах использовать CAT tool с общей памятью переводов. Это значительно упрощает жизнь локализатора при переводе повторяющихся ключей.
Что касается самого процесса разработки, то мы настоятельно рекомендуем избегать переиспользования ключей между разными компонентами и страницами (особенно между разными проектами). Даже если текст в этих ключах одинаковый, все равно рекомендуется использовать два разных ключа. Это позволит избежать неожиданных изменений не в тех местах.
Мы рекомендуем в таких проектах использовать CAT tool с общей памятью переводов.
Спасибо за ответ! Получается, всё сводится к этому пункту (логично) и тогда всё становится на свои места. И уникальные идентификаторы не помеха, т. к. инструмент это сам всё найдет и сопоставит. Собственно, в этом и было мое непонимание. Будучи не более чем любителем (перевод открытого софта и т.п.) я ни разу не видел, чтобы эта память переводов присутствовала или хотя бы нормально работала.
На том же Crowdin дается какое-то одно предложение из (как я теперь прочитал) "глобального Translation Memory" и все. Со стороны проекта можно загрузить свою базу с TM, и тогда вроде нормальнее будет (судя по страницам из их примеров), но мне кажется это неудобно устроено. Но это уже не к вам вопрос. В моем понимании, CAT должен автоматически составлять такую базу на основе предыдущих принятых переводов, шарить её между проектами одной тематической категории и правильно тегировать, чтобы понятно было откуда, что и как (при выборе подсказки). Естественно, подсказок несколько. Может быть в больших профессиональных конторах оно так и работает.
А как обстоит дело с версткой, скажите, пожалуйста?
Cat/tms систему свою пилите или что-то готовое нашли ?
Замечательный вопрос, который достоин отдельной статьи. Попробую ответить на него максимально кратко, но ёмко.
В Яндексе разрабатывают свою TMS (Translation Management System). Этим занимается отдельная команда.
Внутри Яндекса применяются разные CAT tools (Computer-Assisted Translation):
собственные разработки компании;
внешние готовые решения. В данный момент в Фантехе мы используем одно из таких внешних решений из-за его совместимости с ICU Message Format. Внутренние инструменты планируют поддержку ICU, и по завершении этого этапа мы планируем переход на внутреннее решение.
Яндекс был бы не яндексом без запиливания своего решения :).
Если можно поделиться, расскажите- что не устроило в имеющихся решениях.
Мы находили несколько разных - pantoon, weblate, tolgee. Пока изучаем последнюю, выглядит вполне перспективно.
К сожалению, я не обладаю тут полноценной информацией, так как этим занимается другая команда. Но могу предположить, что Яндекс, как большая IT-компании, делает свое решение по нескольким причинам:
Контроль над технологиями и данными.
Уникальные потребности: Разработка собственных продуктов позволяет адаптировать программное обеспечение под конкретные требования и бизнес-процессы компании.
Сложность интеграции: Разработка собственного решения может обеспечить более гладкую интеграцию с текущей системой.
Экономия в долгосрочной перспективе.
Слабо сделать promt2music? ?
Иногда хочется искать музыку не по жанру, а по буквам. И было бы классно, если бы ЯМузыка реализовала такое решение.
Добавила в закладки :-) Спасибо!
Интернационализация от i до n: как мы переводим интерфейсы в Фантехе Яндекса