Comments 66
Хороший текст, о некоторых языках (и их особенностях даже не задумывался).
У меня только один вопрос, что написано на бумажке, на первой фотографии.
У меня только один вопрос, что написано на бумажке, на первой фотографии.
Как раз размышлял над локализацией нового проекта. Спасибо.
Статья очень нужная, спасибо.
Отдельное спасибо за ссылку. Печаль в том, что в России и в Украине многие сами не знают собственных норм написания знаков валют и чисел, либо не подозревают о существовании таких норм. Я пару раз указывал на ошибку в русских текстах типа «… получили $ 5,100.00 прибыли», включая крупные новостные ресурсы. Ответ поражает: «Валюта американская, значит правила написания американские», либо «В оригинале вот-так, значит и в переводе должно быть так».
Отдельное спасибо за ссылку. Печаль в том, что в России и в Украине многие сами не знают собственных норм написания знаков валют и чисел, либо не подозревают о существовании таких норм. Я пару раз указывал на ошибку в русских текстах типа «… получили $ 5,100.00 прибыли», включая крупные новостные ресурсы. Ответ поражает: «Валюта американская, значит правила написания американские», либо «В оригинале вот-так, значит и в переводе должно быть так».
Да, Вы правы, проблема непонятности современных норм нет. Дело в том, что система ГОСТов довольно размыта, очень сложно с ходу найти нужные правила оформления. Как правило, переводческие агентства (а также отделы переводов в больших компаниях) имеют свои внутренние руководства по оформлению чисел, пунктуации и т. д.
Я всё чаще и чаще замечаю, как русскоязычные люди начинают писать по правилам английского языка. Самый яркий пример — написание заголовков и ключевых слов с заглавной буквы, как в английском языке.
Скажем, «Мир Одежды и Обуви» — тут можно подумать, что Одежда и Обувь являются женскими именами. Иначе, зачем бы их писать с заглавной?
И когда всё это переносится на создателей контента, то такое небрежное отношение к языку становится ещё одной проблемой для локализации. В моей практике было немало случаев, когда переводчик присылал перевод, во всех смыслах адекватный оригиналу, включая небрежный стиль. Затем это уже становится головной болью редактора, который шлифует текст до бриллианта, попутно исправляя ошибки не только переводчика, но и того, кто писал исходный текст.
Я всё чаще и чаще замечаю, как русскоязычные люди начинают писать по правилам английского языка. Самый яркий пример — написание заголовков и ключевых слов с заглавной буквы, как в английском языке.
Скажем, «Мир Одежды и Обуви» — тут можно подумать, что Одежда и Обувь являются женскими именами. Иначе, зачем бы их писать с заглавной?
И когда всё это переносится на создателей контента, то такое небрежное отношение к языку становится ещё одной проблемой для локализации. В моей практике было немало случаев, когда переводчик присылал перевод, во всех смыслах адекватный оригиналу, включая небрежный стиль. Затем это уже становится головной болью редактора, который шлифует текст до бриллианта, попутно исправляя ошибки не только переводчика, но и того, кто писал исходный текст.
Прошу прощения, выше хотел написать, что проблема непонятности современных форм существует (в русском языке).
Для себя выделяю следующие ключевые особенности:
1. Локализация — дорогая процедура для внедрения «поверх». Она должна быть заложена в ядре с самого начала.
2. Ресурсы локализации должны быть независимыми от приложения.
3. Если в строки подставляются значения, то должны быть локализированы не просто тексты, а сами шаблоны.
4. При локализации вредно повторное использование элементов. Например, «Сохранить» (файл) и «Сохранить»(настройки) в некоторых языках могут иметь разные названия. Т.е. каждой строке — свой отдельный ресурс, даже если в текущем языке это одна и та же строка. И да, переводить нужно исключительно фразы/предложения целиком.
5. Локализация распространяется не только на строки. И это так же должно быть учтено при проектировании.
1. Локализация — дорогая процедура для внедрения «поверх». Она должна быть заложена в ядре с самого начала.
2. Ресурсы локализации должны быть независимыми от приложения.
3. Если в строки подставляются значения, то должны быть локализированы не просто тексты, а сами шаблоны.
4. При локализации вредно повторное использование элементов. Например, «Сохранить» (файл) и «Сохранить»(настройки) в некоторых языках могут иметь разные названия. Т.е. каждой строке — свой отдельный ресурс, даже если в текущем языке это одна и та же строка. И да, переводить нужно исключительно фразы/предложения целиком.
5. Локализация распространяется не только на строки. И это так же должно быть учтено при проектировании.
Когда вы упомянули о языках, где текст пишется справа налево, возник такой вопрос: а не должно ли это относиться ко всем элементам интерфейса? Например, для европейской локали кнопочки на тулбаре сгруппированы слева (справа — свободное место), а для арабской — наоборот.
В гайдлайнах по локализации MSDN именно так и предлагают делать. Т.е. локализируется интерфейс целиком.
Расположение — понятно. А порядок следования элементов тоже стоит менять на обратный?
[да], [нет], [может быть] --> [может быть], [нет], [да]
Да, как правило, ко всем.
Посмотрите, например, на интерфейс арабского Adobe Acrobat:
Пункты меню и иконки в нём, а также иконки на панели инструментов расположены слева направо.
Посмотрите, например, на интерфейс арабского Adobe Acrobat:
Пункты меню и иконки в нём, а также иконки на панели инструментов расположены слева направо.
Можно еще упомянуть о других календарях и цифрах в некоторых странах
Да, Вы правы, есть разница в представлении даты и времени.
Самый известный, наверное, пример: в России используется форма даты ДД.ММ.ГГГГ, а в Великобритании — ММ.ДД.ГГГГ.
Время может быть представлено как в 24-часовом формате (02:00), так и в 12-часовом (2:00 AM). На Тайване (традиционное китайское письмо), насколько я знаю, иероглифы, описывающие время суток, ставятся перед временем (上午 2:00).
А в промышленном программном обеспечении чаще всего используется универсальное время по стандарту ISO 8601.
Самый известный, наверное, пример: в России используется форма даты ДД.ММ.ГГГГ, а в Великобритании — ММ.ДД.ГГГГ.
Время может быть представлено как в 24-часовом формате (02:00), так и в 12-часовом (2:00 AM). На Тайване (традиционное китайское письмо), насколько я знаю, иероглифы, описывающие время суток, ставятся перед временем (上午 2:00).
А в промышленном программном обеспечении чаще всего используется универсальное время по стандарту ISO 8601.
А я совсем недавно работал примерно над этим механизмом.
Для UTF-16 есть аналогичный класс Wprintf. Механизм почти готов, остаётся придумать т.н. «редкие формы». Например, в русском языке есть четыре формы множественного числа: «один», «мало», «много» и «дробь». Форма «дробь» обычно совпадает с формой «мало», но есть редкие случаи, когда нет. Заодно сокращённая форма — «
std::cout << Printf("{1|Q=Остался ? день,Остались ? дня,Осталось ? дней}")(nDays);std::cout << Printf("Всего {1|q=файл:а,ов}")(nDays);Для UTF-16 есть аналогичный класс Wprintf. Механизм почти готов, остаётся придумать т.н. «редкие формы». Например, в русском языке есть четыре формы множественного числа: «один», «мало», «много» и «дробь». Форма «дробь» обычно совпадает с формой «мало», но есть редкие случаи, когда нет. Заодно сокращённая форма — «
ворон:а,ы,» — не будет работать (даже на целых числах!), если заявить, что в языке четыре формы множественного числа, придётся писать «ворон:а,ы,,ы».…Не будет работать из-за «сокращения сокращения» —
«файл:а,ов». Особенно эта «двойная сокращённая форма» помогает в английском — «file:s».
Пожалуйста, приведите пример, когда формы «дробь» и «мало» не совпадают. А то я уже измучился, пытаясь подобрать, работа стоит…
Куплен 1 рулон
Куплены 2 рулона
Куплено 5 рулонов
Куплено 1,4 рулона
В общем, в хитрых случаях, когда единица измерения — это штука, но штука делимая.
Куплены 2 рулона
Куплено 5 рулонов
Куплено 1,4 рулона
В общем, в хитрых случаях, когда единица измерения — это штука, но штука делимая.
Ещё нашёл с разным ударением. Так что, если в строке есть хинты для синтезатора речи, вот пример.
1 час
2 часа́
5 часов
1,4 ча́са
1 час
2 часа́
5 часов
1,4 ча́са
Сам считал, что их три штуки. Но таблица с unicode.org твeрдит: их всё-таки четыре. Долго искал, пока не нашёл.
А в арабском и валлийском таких форм шесть. Думаю, в этой шестёрке тоже пара форм — редкие.
А в арабском и валлийском таких форм шесть. Думаю, в этой шестёрке тоже пара форм — редкие.
Помимо закрытых «велосипедов» есть ещё открытый и весьма распространённый gettext.
Там в конкретных языковых ресурсах прописывается один или несколько регэкспов — и затем уже прописываются для них соответствующие падежные вариации.
И так можно по вкусу сделать всё вплоть до обзывания однозначных чисел числительными, а двузначных и более — цифрами с соответствующим падежом.
Никаких изменений в код самой программы при этом не требуется — gettext отлично работает поверх.
Там в конкретных языковых ресурсах прописывается один или несколько регэкспов — и затем уже прописываются для них соответствующие падежные вариации.
И так можно по вкусу сделать всё вплоть до обзывания однозначных чисел числительными, а двузначных и более — цифрами с соответствующим падежом.
Никаких изменений в код самой программы при этом не требуется — gettext отлично работает поверх.
принесите флюгегехайнер!!!
UFO just landed and posted this here
А вы случайно не подскажете опенсоурсные веб ориентированные системы которым работают с данными где cтроки имеют id?
Нашел только системы которые работают с форматами без id.
Нашел только системы которые работают с форматами без id.
Типа такого? Конечно, имеется в виду не столько Translatewiki, сколько Extension:Translate. Заодно это будет удобная система перевода документации не выходя из вики.
Ну и Transifex, конечно. Его чуть сложнее установить на свой сервер, но для крупных проектов это просто нечто!
Ну и Transifex, конечно. Его чуть сложнее установить на свой сервер, но для крупных проектов это просто нечто!
Интересуют именно системы которые поддерживают resource id (когда у каждой строки на перевод есть свой id) — первая судя по всему этого не поддерживает
Transifex — копаюсь в документации
Transifex — копаюсь в документации
Нет, Extension:Translate поддерживает.
Key-based formats: each message has a key, usually a more-or-less meaningful string. Translation to every language is a map of keys pointing to values. Most formats fall into this group, including DTD, JSON, and MediaWiki's own format (essentially a PHP array).
К сожалению, нет. Но, когда у меня возникла необходимость, я сам написал фильтры для таких данных с помощью регулярных выражений в привычной себе переводческой среде Kilgray memoQ. Слышал, что возможность создания подобных фильтров есть в SDL Trados Studio 2011, но пока не пробовал. После фильтрования данные (как правило, JSON или YAML, ещё баловался с ресурсами LUA) преобразовывались в XLIFF и отправлялись на перевод. На выходе я получал те же файлы данных с id с тем же синтаксисом, но уже с переведённым текстом. В зависимости от движка приложения иногда языковые идентификаторы приходилось править руками на нужные.
Описанные выше решения, к сожалению, не опенсорсные.
Описанные выше решения, к сожалению, не опенсорсные.
UFO just landed and posted this here
Согласен!
При локализации социальных приложений мы забирали у сети переменную пола пользователя и использовали соответствующую подстановку:
Про пример с сообщением согласен. Числительные более «душевно» выглядят, чем числа. Если, конечно, число не больше, скажем, 20.
При локализации социальных приложений мы забирали у сети переменную пола пользователя и использовали соответствующую подстановку:
{name} [gender:установил|установила] игру «Адское крошилово» и уже [gender:убил|убила] %n зомби!
Про пример с сообщением согласен. Числительные более «душевно» выглядят, чем числа. Если, конечно, число не больше, скажем, 20.
Моё любимое слово для тестирования возможностей системы: Iñtërnâtiônàlizætiøn
А упомянутые популярные XLIFF и .po-файлы все запрошенные фичи поддерживают?
Да. Стоит оговориться, что сами эти форматы ничего не поддерживают, они служат для обмена локализуемыми данными. Грубо говоря, они могут содержать любой текст, который поддерживает Ваш код.
Хотелось бы ещё отметить, что в некоторых системах есть хелперы для локализации дат, времён. Однако, они часто могут создавать проблемы, потому что часто нужных форматов нет, и их всё еще приходится собирать «руками».
Добавлю свои пять копеек. В свое время возились с локализацией и версткой, самый ужас в смысле разлапистых слов — новогреческий.
пароль(рус)
password(англ)
Kennwort(нем)
contraseña(исп)
κωδικού πρόσβασης(греч)
пароль(рус)
password(англ)
Kennwort(нем)
contraseña(исп)
κωδικού πρόσβασης(греч)
С новогреческим, кстати, не приходилось сталкиваться. Спасибо за пример, теперь буду знать, чего ожидать!
С греческим сталкивалась ещё с тем, что при необходимости проверить переводчика иногда сложно разобраться, есть у них там вообще в греческом такое слово или нет. В частности, искала слово bit — и в той же википедии оно было то латиницей, то греческим, поди разберись. Больше проблема подбора персонала, но всё же…
Перед стартом нового проекта тоже задумал сразу же писать с учетом интернационализации.
Добавлю еще к статье алгоритм определения языка интерфейса, к которому я в итоге пришел.
В порядке приоритета (если нет информации по текущему пункту, берем следующий):
1) из параметра url,
2) из cookie,
3) из страны пользователя, определенной с помощью geo-ip,
4) из языка браузера пользователя, если он не английский,
5) язык по умолчанию;
+ возможность сменить язык в панели интерфейса, записав в cookie, т.е. в п.2
Добавлю еще к статье алгоритм определения языка интерфейса, к которому я в итоге пришел.
В порядке приоритета (если нет информации по текущему пункту, берем следующий):
1) из параметра url,
2) из cookie,
3) из страны пользователя, определенной с помощью geo-ip,
4) из языка браузера пользователя, если он не английский,
5) язык по умолчанию;
+ возможность сменить язык в панели интерфейса, записав в cookie, т.е. в п.2
В Drupal «из коробки» практически полностью можно реализовать Ваш алгоритм.
Алгоритм именно таков? Подозреваю есть нюансы, можете поделиться?
Доступны следующие методы определения языка:
1. Определение языка на основе URL (домена или префикса).
2. Определение языка на основе параметра запроса/сессии.
3. Следовать языковым предпочтениям пользователя (у каждого пользователя язык по умолчанию может быть разным).
4. Определение языка на основе настроек языка в браузере.
5. Использовать язык сайта по умолчанию.
Приоритет каждого из методов можно менять в произвольном порядке. Также при смене языка обычно меняется URL и cookie.
1. Определение языка на основе URL (домена или префикса).
2. Определение языка на основе параметра запроса/сессии.
3. Следовать языковым предпочтениям пользователя (у каждого пользователя язык по умолчанию может быть разным).
4. Определение языка на основе настроек языка в браузере.
5. Использовать язык сайта по умолчанию.
Приоритет каждого из методов можно менять в произвольном порядке. Также при смене языка обычно меняется URL и cookie.
Во французском языке вопросительный знак отделяется пробелом
Интересно, что в канадском французском это не так. По официальным правилам такие знаки не отделяются пробелами спереди. Так что даже, казалось бы, для одного и того же языка есть региональные отличия, и не только в пунктуации.
Интересно, что в канадском французском это не так. По официальным правилам такие знаки не отделяются пробелами спереди. Так что даже, казалось бы, для одного и того же языка есть региональные отличия, и не только в пунктуации.
Интересное замечание, спасибо! Интересно также заметить, что из этих же официальных правил видно, что кавычки в Канаде также отбиваются пробелами с двух сторон, как и во Франции. Теперь мне любопытно, почему же отличаются правила по поводу вопросительного знака?..
Скорее всего, просто сложившееся региональное изменение традиции. Ну то есть, ничем разумным это не объясняется :-)
Сами канадцы говорят про их английский, что британцы при встрече с канадским английским принимают его за американский, американцы — за британский. На самом же деле, он отличается от обоих.
Сами канадцы говорят про их английский, что британцы при встрече с канадским английским принимают его за американский, американцы — за британский. На самом же деле, он отличается от обоих.
Скорее всего сказалось влияние английского языка.
Еще один немаловажный пункт локализации — направление написания. Как правило стараются поддерживать два основных LTR (left-to-right), RTL (right-to-left) для азиатских языков, ну а в таких экзотических странах как Монголия где используется TTB (top-to-bottom) о Интернете и компьютере мало кто слышал и слава богу для разработчиков в серьезе озадачившихся локализацией.
Я столкнулся с проблемой, когда нужно поставить в правильном падеже слово, которое идёт в качестве параметра. Вот например,
Иными словами, если в английском имя не меняется, то в русском имя желательно поставить в Дательный падеж (в данном случае). Как самое быстрое решение можно вставить слово «пользователю». Получится вместо «сообщние отправлено Вася Пупкин» что-то типа «сообщение отправлено пользователю Вася Пупкин». Немного коряво, но позволяет обойтись малой кровью. Я пока ещё не нашёл единого верного решения, как справиться с этой задачей наиболее оптимальным путём.
System.out.format("The message was sent to %s %s", user.getName(), user.getSurname());
System.out.format("Сообщение было отправлено %s %s", user.getName(), user.getSurname());
Иными словами, если в английском имя не меняется, то в русском имя желательно поставить в Дательный падеж (в данном случае). Как самое быстрое решение можно вставить слово «пользователю». Получится вместо «сообщние отправлено Вася Пупкин» что-то типа «сообщение отправлено пользователю Вася Пупкин». Немного коряво, но позволяет обойтись малой кровью. Я пока ещё не нашёл единого верного решения, как справиться с этой задачей наиболее оптимальным путём.
Думаю, что в таком случае придётся создавать массив с различными словоформами, релевантными для конкретного языка, а затем подставлять их в текст. В разных языках глаголы могут управлять разными формами существительных.
А вот с именами, наверное, будет сложнее. Если кто-то помнит, в 2007 году ВКонтакте очень часто ошибался со склонением имён и фамилий пользователей. Те, кто замечал, что их имя стоит в неверном падеже, могли сообщить об этом в техподдержку. Вероятнее всего, таким образом «прокачивался» их движок склонения.
Думаю, что каким-то образом у имени распознавалась основа, к которой подставлялось нужное окончание в зависимости от пола пользователя и предыдущих букв. Например, в дательном падеже имена мужского рода получают «у» или «ю», в зависимости от того, обозначает предыдущая буква мягкий звук или твёрдый.
Игорь → Игорю
Александр → Александру
Имена-исключения из правил проще всего собрать по отзывам пользователей. Имена, написанные латиницей, исключаются из склонения.
Вообще, с именами задача очень интересная, думаю о ней уже несколько дней :)
А вот с именами, наверное, будет сложнее. Если кто-то помнит, в 2007 году ВКонтакте очень часто ошибался со склонением имён и фамилий пользователей. Те, кто замечал, что их имя стоит в неверном падеже, могли сообщить об этом в техподдержку. Вероятнее всего, таким образом «прокачивался» их движок склонения.
Думаю, что каким-то образом у имени распознавалась основа, к которой подставлялось нужное окончание в зависимости от пола пользователя и предыдущих букв. Например, в дательном падеже имена мужского рода получают «у» или «ю», в зависимости от того, обозначает предыдущая буква мягкий звук или твёрдый.
Игорь → Игорю
Александр → Александру
Имена-исключения из правил проще всего собрать по отзывам пользователей. Имена, написанные латиницей, исключаются из склонения.
Вообще, с именами задача очень интересная, думаю о ней уже несколько дней :)
Спасибо, хороший текст :)
Sign up to leave a comment.
Пара слов об интернационализации приложений