Пока ещё на политической карте мира границы есть. В мире интернета они давно стёрты.
И вашим сервисом, если он по-настоящему массовый, может воспользоваться и американец, и француз, и аргентинец, и китаец. А значит, вы должны это учитывать в локализации вашего продукта.
И это совсем не так просто, как кажется. Одним переводом массивов текстов о компании и описаний услуг\товаров ограничиться не получится.
Структурируем всё по пунктам:
1. В одной стране не просто может быть, а скорее и очень быстро потребуется более одного языка. Например, в России потребуется русский и английский. В некоторых регионах необходим татарский, украинский, башкирский. Особенности федеративного устройства.
2. Перевод одного и того же языка для разных стран будет разным. Например, переводы маркетинговых текстов на английский для России и Великобритании будут отличаться. Просто потому что совсем другой культурный, исторический, ментальный бэкграунд. Другие триггеры нужны, чтобы цеплять пользователя. «Скажи-ка, дядя, ведь не даром Москва, спаленная пожаром, французу отдана?» — даже переведённая, эмоционально ничего не скажет американцу. Точно так же, как «Twas brillig, and the slithy toves, Did gyre and gimble in the wabe: All mimsy were the borogoves, And the mome raths outgrabe» вызовет у американца просто пожатие плеч от бессмыслицы. Зато англичанин захлопает в ладоши.
Небольшой околопример перевода и ситуации в проекте:
На одном из прошлых моих стартапов собрались в 2014м году выкатываться в Индонезию. Продуктовая часть вроде бы была готова, добивали техническую.
Примерно за 2 недели до часа Х стучится ко мне в скайп наш Гениальный (время примерно 18:00 мск):
- Дим! Ну чё там по срокам?
- Всё норм, всё по срокам.
- Ты знаешь... Я тут в Джакарту прилетел, у меня завтра в 7:00мск презентация нашего сервиса местным министрам! Успеваешь?
OMG... Ситуация - жесть полная. Но что-то же делать надо? Что у нас в наличии? В принципе действительно всё неплохо, надо пару мест подпилить - и выкатится без пары фич. Тогда преза получится норм.
Договариваюсь со всей командой... Ну, как договариваюсь... Кому-то денег обещаю, кому-то отпуск, кому-то увольнение... Решили, короче. Собрались и начали жечь.
Не хватает самой малости - листа текста А4 на индонезийском языке. Без него сервис не будет говорить на родном языке индонезийцев. И обойтись никак. Стучусь к Гениальному:
- Нужен текст на индонезийском!
- Ничем не могу помочь. Я даже на английском не разговариваю!
- Эм.... А ты сейчас где? В такси? Можешь попросить таксиста текст перевести с английского на индонезийский?
- Не могу. Он не знает никакого языка кроме индонезийского...
Ооооооооок! Чешу репу. Снова стучусь к Гениальному:
- А отели какие-то знаешь в Джакарте?
- Да! Хилтон!
Время уже где-то 00:30 мск. Чё делать-то? Терять нечего. Позади Москва.
Звоним в отель, объясняем, что мы несчастные русские стартаперы, хотим осчастливить Индонезию своим стартапом, не хватает листа А4 на индонезийском.
- Вот наш e-mail, присылайте текст, мы переведём!
Через 2 часа мы получили текст и запустились. 3. Если у вас хоть сколько-нибудь нормальный клиент-сайд интерфейс, то переводы потребуется и для него на стороне клиента.
4. Вам потребуется хранить переводы двух типов — короткие фразы (используются для интерфейсов и поясняющих подписей) и длинные тексты (маркетинг, faq, юридическая документация типа оферты и другое).
5. Вам потребуется перевод картинок на языки (причём для разных стран, опять-таки разные). Причём есть картинки, как интерфейсного плана, так и тупо скриншоты. Причём совершенно точно известно, что не все картинки поддадутся автоматизированному наложению генерящихся надписей. И, кстати, для некоторых языков потребуется отдельно доставлять шрифтовые пекеджи.
6. Когда вы соберётесь передавать тексты в перевод, то для каждого короткого текста потребуется комментарий, который описывает контекст, в котором нужен перевод (одно и то же слово, как вы знаете, может иметь несколько значений). Более того, в такой комментарий потребуется точный перечень мест в интерфейс (и как до него добраться), где оно используется. А то напишите для индийской локализации: «Это так же легко, как съесть корову» — и… трудно даже представить.
7. Во всех переводах (коротких и длинных) надо не забыть проставить макросы для вставки как минимум доменных имён и валют, если они отличаются.
8. Таймзона в БД имеет значение. И вывод времени в нужной таймзоне тоже. В отдельных сложных случаях без костылей не обойтись. Например, по тайландскому летоисчислению, сейчас 2560 год. Хотя есть мнение, что в базах лучше не иметь никаких таймзон, UTC и только UTC.
9. Проект must be in UTF-8. Иначе вымрете сразу же. Вывод чисел с десятичной точкой в разных странах отличается. Будьте готовы.
10. Поиск по сайту. Каким бы вы не пользовались движком, важно знать — все европейские языки, включая русский, процессятся специальным стеммером Snowball. Это такая штука, без которой орфография не будет работать вообще. Но для некоторых языков Snowball не хватит — и движок заточенный под работу с ним станет бесполезной обузой. Чтобы решить проблему придётся порыться по интернету и разобраться, какие бывают стеммеры. Да, кстати, для некоторых языков символ пробела (" ") не является разделителем слов (сюрприз!).
Andrey Shetukhin добавляет:
Во-первых, орфография к стеммеру отношения не имеет никакого. Вообще. Ноль.
Во-вторых, тот же сфинкс имеет лемматизатор AOT, изначально написанный Сокирко.
В-третьих, стемминг и лемматизация — абсолютно разные вещи, их нельзя путать.
В-четвёртых, 99.995% разработчиков сайтов самостоятельно решить проблему с поиском не могут. Даже в Авито не справились.
Касаемо разделителя слов. Пробел — не самая большая проблема.
Гораздо важнее знаки препинания, дефисы, специальные символы и модификаторы UTF. Внезапно, й или ё в UTF-8 можно записать несколькими способами. Слово «чёрно-красный«, в зависимости от контекста должно искаться не только исключительно как «чёрно-красный», но и «чернокрасный», «чёрнокрасный», «чёрный красный».
Знаки переноса так же должны учитываться, иначе в поиске будет треш. Кроме того, если речь идёт о русском языке или текстах на русском и английском языках одновременно, необходимо учитывать опечатки в общих буквах для латинского и кириллического алфавитов.
Необходимо уметь обрабатывать сокращения и понимать, где точка используется как знак конца предложения, а где — как элемент сокращения С.С.С.Р., A.C.A.B и т.п.
Всё это очень сложно и большинство разработчиков не имеет достаточного уровня чтобы написать не то, что поиск, а даже токенизатор текста.
11. Никогда не храните исходники текстов в html — вы его тупо не сможете отдать на перевод, который тарифицируется посимвольно. Используйте форматы типа wiki-markup или markdown.
12. Никогда не храните в .po файлах (это способ хранения коротких фраз для переводов с использование упомянутого тут всеми gettext) в лексемах что-либо кроме самого текста.
13. Для gettext не используйте в качестве идентификаторов лексем русскую фразу — вы не сможете такой набор экспортировать на client-side.
14. Время в базе всегда должно быть в UTC. А таймзоны — настройка рендеринга. Как темная и светлая тема, например. (от Сергея Васильева)
15. Не стоит забывать про RTL, про учёт разной плотности на разных языках, про разные сочетания календаря и отображения цифр на разных языках, про сложность выбора формата перевода (.po не очень удобен), про переводческие системы.
Примеры граблей, советов и не всегда с ходу понятных полезностей привёл Дмитрий Симонов ctorecords, СТО и создатель канала «Техдирские заметки» и его многочисленные умудрённые опытом коллеги.
P.S. А кому хочется с пользой усложнить себе жизнь и добавить знания 11—13 декабря пройдёт онлайн-интенсив SRE.
