Этот пост является личным сборником шести независимых от технологий вещей, которые я узнал за последние месяцы о локализации программного обеспечения. Несколько недель назад мы наконец запустили наше приложение, поддерживающее 22 различных языка. Как немецкая команда разработчиков, работающая на немецкого клиента, мы использовали немецкий в качестве базового языка в приложении. Наш клиент отвечал за перевод немецких прикладных сообщений на другие 21 язык и предоставление других локализованных материалов (изображений, загружаемых документов и т. Д.).
1. Используйте инструмент
Вам нужен способ обмена файлами сообщений и переводами между разработчиками и переводчиками. Сначала мы начали использовать простую общую папку в веб-инструменте совместной работы. Мы регулярно загружали новейшую версию немецких базовых файлов сообщений. Переводчики использовали этот файл в качестве справочного материала для обновления файлов сообщений для других языков.
Очевидная проблема с этим подходом состоит в том, что он вызывает много ненужной работы. Каждый раз, когда ключ сообщения был удален, добавлен или переименован, изменение должно быть вручную объединено в 22 файла свойств. Если немецкое сообщение изменилось, мы должны были вручную сообщить переводчикам, чтобы они могли настроить сообщение для других языков. Очевидно, что это не процесс, не хочу.
К счастью, есть несколько хороших инструментов, которые могут помочь вам в процессе перевода. Мы фактически перешли на инструмент с открытым исходным кодом Pootle, который значительно сократил объем ручной работы. Тем не менее, я уверен, что многие альтернативные инструменты доступны. Также обратите внимание, что для этого вам не обязательно нужен сторонний инструмент. Если вы предпочитаете сохранять локализованные сообщения в базе данных, вы можете легко создать пользовательский интерфейс CRUD с простой функцией поиска, которая затем может использоваться переводчиками для обновления сообщений.
2. Научите переводчиков
Вы должны убедиться, что переводчики полностью понимают синтаксис сообщений. Для разработчика может быть очевидным, как работают заполнители, экранирование и форматы даты. С точки зрения переводчика (который может вообще не иметь никакого опыта в разработке программного обеспечения) вещи не всегда так очевидны. Если ваше приложение дает сбой с исключениями формата даты на определенных языках, потому что формат даты DD.mm.YYYY переведен на jour / mois / an (день / месяц / год на французском языке), вы знаете, что вам нужно улучшить этот пункт.
Обязательно сообщите им, как работают заполнители и какие специальные символы необходимо экранировать. Дайте им примеры общих шаблонов даты / времени, включая результаты, которые они производят. Используйте комментарии в файлах сообщений, чтобы предоставить общие параметры форматирования или объяснить заполнители, которые можно использовать в сообщениях.
3. Дайте переводчикам контекст
Просто перевода сообщений с одного языка на другой часто недостаточно. Переводчики должны знать контекст, в котором отображается сообщение, чтобы обеспечить соответствующий перевод. Первым шагом здесь является предоставление им доступа к тестовой системе, где они могут видеть приложение с последней версией своих переводов.
Мы регулярно получали письма от переводчиков с такими вопросами:
В приложении я вижу сообщение X в позиции Y. Что такое ключ сообщения для X?
В зависимости от сообщения X простой поиск X в файлах сообщений не всегда помогает (подумайте о заполнителях, дополнительной разметке или слишком большом количестве сообщений, содержащих X). Нашим решением было расширить способ отображения сообщений для пользовательского интерфейса. После этого стало возможным отображать ключи сообщений в тестовой среде, добавив в URL нашего приложения дополнительный параметр url. Всякий раз, когда этот параметр url добавлялся, мы добавляли простой тег <span> с атрибутом title вокруг отображаемых сообщений. Поэтому вместо [message] мы визуализировали <span title = ”[key]”> [message] </ span>. Это позволило просто навести на экран отображаемое сообщение мышью, чтобы увидеть небольшую подсказку, на которой показан ключ сообщения. Этот подход не является на 100% пуленепробиваемым, потому что в некоторых ситуациях дополнительный <span> нарушает макет. Тем не менее, в 95% случаев он работает нормально, и это значительно уменьшило количество вопросов, которые мы получили от переводчиков.
Существует и противоположный способ:
Я вижу сообщение X с ключом Y в файле сообщений. Где это отображается в приложении?
Я думаю, что лучшее решение для этого — следовать логическому соглашению об именах ключей сообщений. Мы использовали следующее простое соглашение для структурирования ключей сообщений:
|
1
|
[module].[section].[detail].[optional subdetail] |
Несколько примеров:
|
1
2
3
|
news.create.title=Titlenews.create.title.emptyError=Please add a titlenews.create.title.maxLengthExceededError=The title cannot be longer than X characters |
Это некоторые сообщения, отображаемые в поле ввода заголовка формы создания (раздела) в модуле новостей. Уровни организации разделены точками. Описание ошибки, такое как maxLengthExceeded, не описывает организацию, поэтому оно написано в случае верблюда вместо news.create.title.max.length.exceeded.
Тем не менее, это только предположение, которое отлично работало для нашего использования. Не стесняйтесь придумать свое собственное соглашение.
4. Имейте в виду, ширина слова может варьироваться
В зависимости от вашего базового языка вы должны знать, что среднее количество символов на слово может быть намного выше или ниже на других языках. Я не нашел никакой реальной статистики средней длины слова, но я могу показать вам некоторые цифры из наших файлов сообщений:
Среднее количество символов в слове:
| язык | Символы | фактор |
| английский | 5,3 | 1 |
| португальский | 5,5 | 1,04 |
| французкий язык | 5,7 | 1,07 |
| Немецкий | 6,4 | 1,21 |
| русский | 6,7 | 1,25 |
Это средние числа, взятые из файлов сообщений с примерно 1500 сообщениями на файл. Обратите внимание, что эти цифры не так точны. Чтобы получить слова сообщения, я просто разделяю сообщения на пробелы. Слова и сообщения могут содержать дополнительную разметку, пунктуацию или заполнители. Однако, поскольку разметка и заполнители в большинстве случаев одинаковы для всех языков, она все же дает некоторую полезную информацию. В нашем приложении отдельные слова на немецком или русском языке примерно на 20% длиннее английских.
Вы должны убедиться, что пользовательский интерфейс вашего приложения поддерживает различные размеры текста. Это особенно важно для кнопок и элементов навигации, которые обычно расширяются, если их метки становятся больше. Также помните, что общие сокращения на одном языке могут быть переведены в одно (или, может быть, больше) полных слов на других языках. Например, FAQ или Q & A — это два часто используемых элемента навигации на английских веб-страницах. Хотя сообщение « Вопросы и ответы» может быть переведено на разные языки, для этого не всегда существует общее сокращение.
5. Проверьте это
Всесторонне протестируйте локализованное приложение: проверяйте переводы, используйте не западные символы в качестве пользовательского ввода и проверяйте функциональность для всех языков. Чтобы подчеркнуть важность тестирования, я просто хочу привести несколько примеров локальных проблем, с которыми мы столкнулись:
- Пользователи определенного языка не получили определенного электронного письма. Оказалось, что письмо содержало дату, отформатированную в зависимости от локали. Шаблон содержал недопустимый символ, сбой форматирования даты и электронное письмо не было отправлено пользователю.
- В некоторых ситуациях заполнители не заменялись фактическим контентом на французском языке. Проблема была вызвана сообщениями, содержащими неэкранированные одинарные кавычки. В Java MessageFormat заполнители не заменяются, если они расположены между двумя неэкранированными одинарными кавычками. Мы заметили эту проблему только на французском языке, потому что французские сообщения содержат гораздо больше одинарных кавычек, чем сообщения на других языках, которые мы поддерживаем.
- Элементы пользовательского интерфейса сломались, потому что переведенные сообщения были слишком длинными и не помещались в зарезервированное пространство.
- Оказалось, что используемый нами внешний платежный провайдер не поддерживает полный набор символов UTF-8. Поэтому кириллические символы не могут быть напечатаны на счетах.
6. Требуется время
Весь процесс локализации может занять много времени. Особенно, если в нем участвует много людей из разных стран. Поэтому убедитесь, что все спланировано правильно. Помните, что каждое текстовое сообщение, которое вы добавляете в приложение, должно быть переведено.
Однажды мы добавили небольшую функцию, которая заняла около одного дня в разработке. После того, как разработка была завершена, прошло около трех недель, пока мы не смогли внедрить эту функцию в работающую систему. Некоторые переводчики были в отпуске, и в некоторых странах юридические вопросы должны были быть разъяснены. Кроме того, у нас были некоторые зависимости между переводчиками. Как упоминалось выше, мы использовали немецкий в качестве базового языка, но не каждый переводчик понимал немецкий. Поэтому в некоторых случаях немецкие сообщения должны были быть переведены на английский язык, прежде чем они могли быть переведены на другие языки.
С точки зрения разработчиков, это не должно быть плохо. На самом деле это очень хорошее оправдание, если заказчик или руководитель проекта спрашивает вас за день до выпуска производства, можете ли вы добавить функции X и Y до завтра. Конечно, вы можете добавить его, но нет никаких шансов, что он будет локализован до завтра, поэтому лучше спланировать его правильно и перенести в следующий выпуск!