Грабли реализации мультиязычной поддержки в десктопном софте

Впервые мультиязычность в моих продуктах появилась примерно десять лет назад. По мере внедрения этого появились трудности и проблемы. О них и заострю внимание.

Немного из истории

Почему я ввел мультиязычность? Потому что по результатам мониторинга посещаемости оказалось, что значительная доля пользователей приходила из неанглоязычных стран. Параллельно с этим возросла нагрузка на саппорт на разных языках и появились люди, кто предлагал сделать перевод. На тот момент времени у меня было уже четыре продукта и один новый продукт предполагался к разработке. Было решено попробовать внедрить это на одном из самых массовых продуктов. А новый продукт писать изначально с поддержкой этого.

Что было и сделано. Я написал свой формат текстового языкового файла на основе INI-подобного языка ключ=значение, какой еще использовался и для хранения установок программы. В него просто были внедрены расширения для возможности сохранения значений из нескольких строк, что было важным в некоторых из моих программ.

Изначально я реализовал русский и английский и вывесил на сайте объявление, что лицензия бесплатно тому, кто переведет это. При загрузке программы подгружался английский язык, а затем грузился выбранный пользователем. Вся информация о текстах записывалась в память программы, откуда уже забиралась во время инициализации и отрисовки. Такая идея спасла позже, когда оказалось, что переводы на языки, какие я не мог поддерживать, по версии отставали от текущей версии на одну или две. Так что пользователь видел хотя бы английский текст, если что-то отличалось по версии.

За лет пять накопилось около десятка языков, и появилась следующая проблема. Я раздавал лицензии, но терял координаты переводчиков. Поэтому пришлось заставлять их вписывать свои емейлы в метаданные языкового файла. Но это оказалось лишним. Дело в том, что большая часть этих контактов оказывалась невалидной через год-два или переводчик вообще не отвечал на сообщение. Так что, постепенно, у меня скопилось такое количество изменений, что продукт перестал нормально выглядеть на целом ряде очень важных языков. И я принял решение изменить все кардинально.

Но тут появилась другая проблема, какую я не учитывал. Я снес все невалидные языковые файлы из дистрибутива с ожиданием, что новые пользователи пришлют новые языковые файлы, раз старые переводчики или терялись или «забивали болт». Но желающих оказалось в разы меньше, чем в прошлые годы. Так что могу сказать, что за последние пять лет стало гораздо меньше желающих сделать перевод в обмен на лицензию.

Еще оказалось, что при обновлении на новую версию, при установке, старые языковые файлы оставались на своих местах, так что пользователь получал неправильную отрисовку. И программой было очень трудно пользоваться, поскольку некоторые тексты просто напросто отсутствовали. Моя система дала сбой.

Дальше опишу уже не так подробно, а тезисно, другие грабли, с которыми пришлось столкнуться:

* Совершенно зря в первых версиях я вносил тексты о цене программы. Цена менялась очень часто. Влияния же на то, что разбрелось по интернету, у меня не было.

* Ошибочный порядок загрузки языкового файла и данных об активации в проверке лицензии. В ряде случаев пользователю всегда показывался английский, даже если в настройках был другой язык. В итоге, я терял очень много покупателей, ведь им показывалось сообщение не на родном языке про окончании триала. Терялся значительный маркетинговый рычаг — на месте пользователя не было ясно, что происходит с программой. Исправление этого увеличило продажи больше чем в полтора-два раза на локализованных случаях.

* Важен удобный доступ к тексту для удобства программирования. Изначально я грузил всё в переменные программы, а затем получал значение в нужном месте, просто присваивая. По мере роста программы это стало чудовищно неудобным — надо было менять тексты в нескольких местах, что приводило порой к ошибкам и вообще замедляло разработку. Замена доступа через вызов функции типа GetText('SomeCode') упростило программирование.

* Не нужно отказыватья от родного языка. Стали присылать переводы на русский те, кто не являлся русским — были даже поляки и чехи. Перевод был не очень хорошим. Так что я вернулся обратно к тому, что сам стал писать русский текст.

* Язык на котором я писал, не поддерживал юникод. Это была значительная проблема Turbo Delphi Explorer, можно сказать, одна из самых главных, почему пришлось побыстрее с нее сматываться куда подальше. Но до сих пор я вынужден использовать ее на старых продуктах. И имею целый ряд проблем на ряде продуктов, работающих с web-даными, где уже давно стандартным является utf-8. Работать с этим внутри программы еще можно, но отрисовывать это, а особенно редактировать — существенная проблема. Плюс, как всегда, имеем стандартную проблему работы с буфером обмена. Прежде чем что-то скопировать из программы, нужно переключаться на нужную раскладку, иначе получим просто нечитаемый текст. Лично меня это достает. До сих пор пользуюсь кучей неюникодных программ, где ежедневно приходится копировать русские тексты.

* Существует проблема взаимодействия программы с сайтом. На сайте один список поддерживаемых языков, а в программе другой. Куда посылать пользователя?

* Готовьтесь к тому, что когда у вас появится локализация на язык, какой вы не знаете, в саппорт к вам будут писать на незнакомом вам языке. Дистанция между взаимопониманием увеличивается.

Несколько решений, какие я считаю верными и работающими:

* Не нужна мультиязычность на всех программах. Большинство разработчиков знают английский и используют только его. Это справедливо и в медиапроизводстве — графика, дизайн и видео. Тут огромное количество терминов из research, какие проводились больше в US, так что все предпочитают пользоваться именно английскими терминами, а не с исковерканными локализациями. Так что у меня не на всех продуктах есть поддержка многоязычности.

* Я сознательно отказался от поддержки азиатских языков и иврита. Там настолько много особенностей, что не имея в составе разработчиков того, кто оттуда родом, невозможно это корректно реализовать. Так что нет смысла этого делать.

Спорные решения:

* На настоящий момент считаю упор на энтузиастов не работающим. Во-первых, за десять последних лет спрос на это упал, во-вторых, они неуправляемы. Очень неприятно находиться в дилемме — стоит ли реализовать некоторую фичу или изменить что-то, что задействует смену текстов, или лучше попытаться отказаться от изменения текстов.

В-целом, это все, что я хотел сказать. Хотелось бы увидеть в обсуждении что-то из ваших находок и описание ваших граблей. Я статью писал потому, что сейчас у меня планируется переработка итераций поддержки мультиязычности, поэтому нуждаюсь в свежем взгляде на мультиязычную проблему.

Грабли реализации мультиязычной поддержки в десктопном софте

Впервые мультиязычность в моих продуктах появилась примерно десять лет назад. По мере внедрения этого появились трудности и проблемы. О них и заострю внимание.

Немного из истории

Почему я ввел мультиязычность? Потому что по результатам мониторинга посещаемости оказалось, что значительная доля пользователей приходила из неанглоязычных стран. Параллельно с этим возросла нагрузка на саппорт на разных языках и появились люди, кто предлагал сделать перевод. На тот момент у меня было уже четыре продукта и один новый продукт предполагался к разработке. Было решено внедрить это на одном из самых массовых продуктов. А новый продукт писать изначально с поддержкой этого.

Что было и сделано. Я выбрал свой формат текстового языкового файла на основе INI-подобного языка ключ=значение, какой у меня еще использовался и для хранения установок программы. В него просто были внедрены расширения для возможности сохранения значений из нескольких строк, что было важным для некоторых моих программ. Вся информация о текстах записывалась в память программы, откуда уже забиралась во время инициализации и отрисовки.

Изначально я реализовал русский и английский. Повесил на сайте объявление, что лицензия будет бесплатно тому, кто переведет это. При загрузке программы подгружался английский язык, а затем грузился выбранный пользователем. Такая идея спасла позже, когда оказалось, что переводы на языки, какие я не мог поддерживать, по версии отставали от текущей на одну или две. Так что пользователь видел хотя бы английский текст, если чего-то еще не было в локализованном варианте.

Через пять лет программа поддерживала уже десяток языков, и с этим появилась новая проблема. Я раздавал лицензии, но терял координаты переводчиков. Поэтому пришлось заставлять их вписывать свои емейлы в метаданные языкового файла. Но это оказалось лишним. Дело в том, что большая часть этих контактов оказывалась невалидной через год-два. Или переводчик вообще не отвечал на сообщения. Так что, постепенно, у меня скопилось такое количество изменений, что продукт перестал нормально выглядеть на целом ряде очень важных языков. И я принял решение изменить все кардинально.

Но тут появилась другая проблема, какую я не учитывал. Я снес все невалидные языковые файлы из дистрибутива с ожиданием, что новые пользователи пришлют новые языковые файлы, раз старые переводчики постепенно или терялись или «забивали болт». Но желающих перевести оказалось в разы меньше, чем в прошлые годы. Так что, могу сказать, что за последние пять лет стало гораздо меньше желающих сделать перевод в обмен на лицензию.

Еще оказалось, что при обновлении на новую версию, при установке, старые языковые файлы оставались на своих местах, и пользователь получал неправильную отрисовку. И программой было очень трудно пользоваться, поскольку некоторые тексты в этом случае просто-напросто отсутствовали или уже имели несколько иной смысл, чем было в старых версиях. Моя система дала сбой.

Дальше опишу уже не так подробно, а тезисно, другие грабли, с которыми пришлось столкнуться:

* Совершенно зря в первых версиях я вносил тексты о цене программы. Цена менялась очень часто. Влияния же на то, что разбрелось по интернету, у меня не было.

* Ошибочный порядок загрузки языкового файла и данных об активации в проверке лицензии. В ряде случаев пользователю всегда показывался английский, даже если в настройках был другой язык. В итоге, я терял очень много покупателей, ведь им показывалось сообщение не на родном языке про окончании триала. Терялся значительный маркетинговый рычаг — на месте пользователя не было ясно, что происходит с программой. Исправление этого увеличило продажи больше чем в полтора-два раза в локализованных случаях.

* Важен удобный доступ к тексту для облегчения программирования. Изначально я грузил всё в переменные программы, а затем получал значение в нужном месте, просто присваивая. По мере роста программы это стало чудовищно неудобным — надо было менять тексты в нескольких местах, что приводило порой к ошибкам и вообще замедляло разработку. Замена доступа через вызов функции типа GetText('SomeCode') упростило программирование.

* Не нужно отказываться от родного языка. Стали присылать переводы на русский те, кто не являлся русским — были даже поляки и чехи. Перевод был не очень хорошим. Я вернулся обратно к тому, что сам стал писать русский текст.

* Среда программирования не поддерживала юникод. Это была значительная проблема Turbo Delphi Explorer, можно сказать, одна из самых главных, почему пришлось побыстрее с нее сматываться куда подальше. Но до сих пор я вынужден использовать ее на старых продуктах. И имею целый ряд проблем на ряде продуктов, работающих с web-даными, где уже давно стандартным является utf-8. Работать с этим внутри программы еще можно, но отрисовывать это, а особенно редактировать — существенная проблема. Плюс, как всегда, имеем стандартную проблему работы с буфером обмена. Прежде чем что-то скопировать из программы, нужно переключаться на нужную раскладку, иначе получим нечитаемый текст. Лично меня это достает. До сих пор пользуюсь кучей неюникодных программ, где ежедневно приходится копировать русские тексты.

* Существует проблема взаимодействия программы с сайтом. На сайте один список поддерживаемых языков, а в программе другой. Куда посылать пользователя?

* Готовьтесь к тому, что когда у вас появится локализация на язык, какой вы не знаете, в саппорт к вам будут писать на незнакомом вам языке. Дистанция между взаимопониманием увеличивается. Нагрузка на саппорт растет.

Несколько решений, какие считаю верными и работающими:

* Не нужна мультиязычность на всех программах. Большинство разработчиков знают английский и используют только его. Это справедливо и в медиапроизводстве — графика, дизайн и видео. Тут огромное количество терминов из research, какие проводились больше в US, так что все предпочитают пользоваться именно английскими терминами, а не исковерканными локализациями. Так что, у меня не на всех продуктах есть поддержка многоязычности.

* Я сознательно отказался от поддержки азиатских языков и иврита. Там настолько много особенностей, что не имея в составе разработчиков-нейтивов, невозможно это корректно реализовать. Так что, нет смысла этого делать.

Спорные решения:

* На настоящий момент считаю упор на энтузиастов не работающим. Во-первых, за десять последних лет спрос на это упал, во-вторых, они неуправляемы. Очень неприятно находиться в дилемме — стоит ли реализовать некоторую фичу / изменить что-то, что задействует смену текстов, или лучше попытаться отказаться от изменения текстов.

В-целом, это все, что я хотел сказать. Хотелось бы увидеть в обсуждении что-то из ваших находок и описание ваших граблей. Я статью писал потому, что сейчас у меня планируется переработка итераций поддержки мультиязычности, поэтому нуждаюсь в свежем взгляде на проблему.