Русский
Русский
English
Статистика
Реклама

Internationalization

Интернационализация и локализация приложения на KotlinNative

22.03.2021 18:15:22 | Автор: admin

, или добрый день по-японски.

Как бы не был популярен английский язык, всё же пользователям комфортнее и привычнее в родной языковой среде.

Поэтому далее мы пошагово рассмотрим процесс адаптации консольного приложения для Linux на Kotlin/Native к русской и английской локали.

Поможет нам в этом старый-добрый GNU gettext.

В итоге убедимся, что это совсем не страшно.

Заодно посмотрим интеграцию с библиотеками на C, которая значительно расширяет возможности Kotlin/Native.

Что напишем: переводчик количественных числительных на японский язык.

Что ожидается от читателя: знание языков программирования Kotlin, C, базовый уровень знакомства с ОС Linux (в частности Bash).

Что понадобится в процессе: любой дистрибутив Linux, любая версия IntelliJ IDEA, установленный пакет gettext-devel или аналогичный.

Мотивация

Собственно почему Kotlin/Native и причём тут японский

Где-то полгода медленно и печально изучаю японский язык по учебнику Minna no Nihongo: частью ради перевода текста песен, частью просто из интереса к культуре.

Позже решил перейти с системной разработки на прикладную, с десктопа на мобильные платформы, соответственно с C++/Qt/STL на Kotlin/JVM/Android SDK.

Теперь хочу два этих занятия совместить, написав для себя программы для помощи в изучении японского. Конечно, уже много готовых, но NIH-синдром ведь не что-то плохое, правда?

Раньше я не задумываюсь использовал бы связку Qt/QML/C++: она позволяет быстро и эффективно решать в общем-то любые задачи и на любой платформе.

Однако Qt всё больше поворачивается спиной к Open Source, вот и решил пора валить попробовать что-то другое.

И тут в процессе изучения Kotlin узнал про Kotlin/Native.

Соответственно, первая программа-помощник будет именно на нём.

Что такое Kotlin/Native

Изначально Kotlin выступал в качестве "более лучшей" (С) Java, и целиком опирался на платформу JVM.

Однако затем компания JetBrains, разработчик Kotlin, решила адаптировать набирающий популярность язык и под другие платформы.

В частности, под веб (Kotlin/JS) и под "натив" (Kotlin/Native).

Kotlin/Native появился в марте 2017 года, кстати ровно четыре года назад.

Он позволяет компилировать код на Kotlin в нативный код с помощью LLVM, без зависимости от виртуальной машины JVM и других библиотек.

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

Из плюсов:

  • исходный код под пермиссивной открытой лицензией (Apache-2.0 license)

  • работа на всех поддерживаемых LLVM платформах, в частности iOS и десктопы

  • генерирует единственный исполняемый файл без сторонних зависимостей

  • низкое потребление системных ресурсов

  • доступны все базовые "вкусности" Kotlin вроде коллекций и функционального программирования

  • есть прозрачный interop с языком C

  • как следствие: доступны low-level функции платформы, в частности POSIX

Из минусов:

  • стандартная библиотека весьма бедная по сравнению с огромной JVM, многое придётся писать с нуля (пример: оставьте только пункт Native тут)

  • нет стабильной библиотеки для GUI, хотя есть некоторые привязки через C interop (GTK, libui)

  • слабый инструментарий по сравнению с той же Android Studio, например нет той же локализации

  • относительно долгое время сборки

Больше о Kotlin/Native можно почитать тут, а примеры доступны на Github.

Терминология

Интернационализация (i18n): подготовка приложения к локализации, обычно выполняется разработчиками.

Локализация (l18n): Процесс перевода и адаптации контента приложения для конкретных языков, обычно выполняется переводчиками.

Важно: "контент" тут это не только строки, но и направление текста, формат даты, чисел и так далее. В данной статье ограничусь только строками.

Что такое GNU gettext

Этот пакет из нескольких утилит, библиотек и регламентов.

Является частью GNU Translation Project.

Состоит из:

  • правила оформления исходного кода для последующей интернационализации

  • утилиты для генерации текстовых файлов с локализуемыми строками

  • кроссплатформенная нативная библиотека для извлечения переводов в runtime

  • правила дистрибуции бинарных файлов с переводами

Почему GNU gettext

Интернационализация в Kotlin/JVM для Android использует средства Android SDK, в частности строковые ресурсы, и завязана на JVM.

Поэтому для Kotlin/Native эти средства недоступны.

В Qt есть собственный инструментарий, но его не получится использовать вне Qt, тем более с отличным от C++ языком.

Поэтому остаётся GNU gettext:

  • универсальный (поддерживается множество языков программирования)

  • кроссплатформенный (Win/Mac/Linux, есть Android/iOS версия)

  • стабильный в силу почтенного возраста

  • с подробной документацией

  • со вспомогательными приложениями

Демонстрационный проект

Суть: консольная программа пока только под Linux, чтобы не переусложнять код.

Функционал: читает натуральное число из аргумента командной строки или stdin, и переводит его в количественное числительное на японском.

Число может содержать специфичные для локали разделители тысяч, которая программа выводит при запуске.

Скачать проект можно на Github и затем открыть в IntelliJ IDEA.

Характеристики исполняемых файлов

Для начала время полной сборки: ~18 сек на конфигурации Ryzen 3900X + 32GB DDR4-3600 + NVM-E SSD. На мой взгляд многовато для такого маленького проекта и такой конфигурации.

Тут можно вспомнить о преимуществах скриптовых языков, которые компилировать не надо.

Теперь посмотрим свойства исполняемого файла для отладочной и релизной конфигураций:

Размеры скомпилированных исполняемых файлов
$ file build/bin/native/debugExecutable/JapaneseNumeralTranslator.kexebuild/bin/native/debugExecutable/JapaneseNumeralTranslator.kexe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.16, BuildID[xxHash]=a0971dbf76e9db60, with debug_info, not stripped$ ldd build/bin/native/debugExecutable/JapaneseNumeralTranslator.kexelinux-vdso.so.1 (0x00007fff890d7000)libdl.so.2 => /lib64/libdl.so.2 (0x00007f348e47a000)libm.so.6 => /lib64/libm.so.6 (0x00007f348e334000)libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f348e312000)libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f348e2f7000)libc.so.6 => /lib64/libc.so.6 (0x00007f348e12c000)/lib64/ld-linux-x86-64.so.2 (0x00007f348e4a0000)libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f348e112000)libutil.so.1 => /lib64/libutil.so.1 (0x00007f348e10b000)libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f348e0d1000)librt.so.1 => /lib64/librt.so.1 (0x00007f348e0c6000)$ file build/bin/native/releaseExecutable/JapaneseNumeralTranslator.kexe build/bin/native/releaseExecutable/JapaneseNumeralTranslator.kexe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.16, BuildID[xxHash]=c76aff5e0db3fdae, not stripped$ ldd build/bin/native/releaseExecutable/JapaneseNumeralTranslator.kexe linux-vdso.so.1 (0x00007ffff69c2000)libdl.so.2 => /lib64/libdl.so.2 (0x00007f41ad9dd000)libm.so.6 => /lib64/libm.so.6 (0x00007f41ad897000)libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f41ad875000)libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f41ad85a000)libc.so.6 => /lib64/libc.so.6 (0x00007f41ad68f000)/lib64/ld-linux-x86-64.so.2 (0x00007f41ada03000)libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f41ad675000)libutil.so.1 => /lib64/libutil.so.1 (0x00007f41ad66e000)libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f41ad634000)librt.so.1 => /lib64/librt.so.1 (0x00007f41ad629000)$ ls -lh build/bin/native/debugExecutable/JapaneseNumeralTranslator.kexe-rwxr-xr-x. 1 eraxillan eraxillan 1.8M Mar  7 13:24 build/bin/native/debugExecutable/JapaneseNumeralTranslator.kexe$ ls -lh build/bin/native/releaseExecutable/JapaneseNumeralTranslator.kexe -rwxr-xr-x. 1 eraxillan eraxillan 529K Mar  7 13:24 build/bin/native/releaseExecutable/JapaneseNumeralTranslator.kexe

Тут всё в порядке, бинарники скромные по размеру и без каких-либо сторонних зависимостей.

Отладка проекта

Она не работает, по крайней мере в Community Edition.

Просто игнорируются точки останова, хотя судя по выводу команды file отладочные символы в исполняемом файле есть.

Насколько я понял, соответствующий плагин доступен только в платной редакции IDE, которая пока для меня избыточна.

Прошу поправить, если ошибаюсь.

Так что для написания демо пришлось обходиться printf-driven отладкой, ну мне не привыкать после Android AOSP.

Интернационализация

В случае нашего проекта нужно лишь все локализуемые строки "обернуть" в вызов функции gettext().

Для краткости можно сделать синоним этой функции, например tr(), это общепринятая практика.

import kotlinx.cinterop.*import platform.linux.*import platform.posix.*fun tr(key: String): String = gettext(key)?.toKString() ?: ""

Понадобится ещё служебный код для работы с POSIX-локалями, он находится в файле Locale.kt.

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

Кстати, посмотреть названия локалей можно с помощью команды locale -a.

Перевод локализуемых строк

Я написал Bash-скрипты для генерации с нуля и обновления файлов gettext:

Далее вкратце опишу основные шаги, которые они выполняют.

Генерируем pot-файл ("шаблон"), который содержит базовую информацию о программе и собственно строки нуждающиеся в переводе.

# Extract all tr() wrapped strings to po/jnt.pot filexgettext --keyword=tr --language=java \    --add-comments --sort-output \    --copyright-holder='Alexander Kamyshnikov <axill777@gmail.com>' \    --package-name='Japanese numeral translator' \    --package-version='1.0' \    --msgid-bugs-address='axill777@gmail.com' \    -o po/jnt.pot --files-from=KT_FILES

Генерируем po-файл (текстовый перевод):

# Generate locale sources# NOTE: --no-translator option is a workaround to supress email input requestmsginit --no-translator --input=po/jnt.pot --locale=en_US.UTF-8 --output po/en_US/jnt.pomsginit --no-translator --input=po/jnt.pot --locale=ru_RU.UTF-8 --output po/ru_RU/jnt.po

Генерируем mo-файл (бинарный перевод):

# Generate locale binary filesmsgfmt --output-file=po/en_US/jnt.mo po/en_US/jnt.pomsgfmt --output-file=po/ru_RU/jnt.mo po/ru_RU/jnt.po

Развертывание бинарных файлов с переводами

К сожалению, Kotlin/Native не поддерживает ресурсы, так что "упаковать" mo-файлы в исполняемый файл пока не выйдет.

На это есть соответствующий баг.

Думаю, функционал ресурсов можно реализовать и вручную дополнительной задачей в Gradle, это пожалуй тема для отдельной статьи.

Для тестового проекта положим mo-файлы рядом с приложением, где не нужны права суперпользователя и где gettext сможет их найти.

Для релиза приложение следует упаковать в RPM/DEB-пакет, а mo-файлы установить в директорию /usr/share/locale.

Итог

Как видите, процесс несложен, по крайней мере при наличии готового кода и скриптов.

В процессе разработки нужно лишь периодически вызывать update_localization.sh, переводить новые строки, и снова вызывать этот скрипт для генерации mo-файлов.

, или спасибо за внимание!

Источники

Определения взяты из документации Django

Почему интернационализация и локализация имеют значение

Kotlin Native: следите за файлами

DxGetText GNU Gettext for Delphi and C++ Builder

P.S.: дальше планирую использовать Kotlin/Native уже в рамках кроссплатформенных библиотек. Если будет интерес, могу доработать демо, например портировать на Windows.

Подробнее..

Советы по эффективной локализации продукта

16.07.2020 12:18:27 | Автор: admin


Локализация это воплощение принципа удобства для пользователя: примерно 75% людей в мире чувствуют себя более свободно и уверенно при использовании продуктов на родном языке, а не на английском.


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


Сложности локализации на стыке с разработкой


Компании, не уделяющие должного внимания планированию локализации, часто делают ошибки, которых можно было избежать. Основная проблема возникает из-за неверно выстроенных отношений между разработчиками, менеджерами по локализации и переводчиками. Отдаваемые на перевод тексты (обычно это пользовательский интерфейс) и локализованные версии не обновляются синхронно. Например, код для определенных текстовых областей может не учитывать, что некоторым языкам потребуется больше места и это приходится исправлять вручную.


Это не единственная неприятность: может получиться и так, что в новых географических регионах запуск придется откладывать. Часто менеджеры с опозданием узнают, что переведено не всё или разработанный продукт не полностью адаптирован к местным стандартам. И чтобы успеть, приходится спешить а спешка снижает качество.


Правильный подход с самого начала


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


Переводческие компании часто могут посоветовать процессы и удобные инструменты управления переводами для конкретной задачи. К примеру, мы в Alconost, часто разрабатываем собственные коннекторы для интеграции систем управления контентом, что позволяет добиться высокой степени автоматизации.


Этапы локализации продукта и рекомендации


В стратегии по локализации важны налаженные процессы и конкретные инструкции: они обеспечивают эффективную локализацию в рамках разработки цифровых продуктов.


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


Этап 1. Проверка исходных текстов


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


Кроме того, исходные материалы должны пройти оценку по культурным, техническим и лингвистическим аспектам (этим может заняться компания по локализации).


Этап 2. Тестирование локализации (псевдо-локализация)


Следующий этап это обычно запуск пилотного языка (не английского) для того, чтобы проверить, готова ли стабильная версия продукта к локализации. Протестировав возможность локализации на одном языке, можно определить проблемные области разработки и дизайна элементов интерфейса.


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


Этап 3. Работа со сторонней компанией по локализации


На этом этапе рекомендуется остановить изменения в пользовательском интерфейсе, заблокировать контент и перенести обновления на будущий спринт. Переводческой компании нужно передать все необходимые материалы и сведения, в том числе об используемых для перевода инструментах и программном обеспечении (облачных платформах, CRM, CMS и других инструментах для перевода). Для автоматизации и оптимизации качества переводов часто используются платформы управления переводами (например, Crowdin), в которых работают все стороны, в том числе агентства по локализации.



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


Хорошего результата помогает добиться регулярное общение внутри платформы для перевода, организационный колл по запуску локализации и еженедельные контрольные звонки.


Этап 4. Оценка качества перевода


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


Этап 5. Исправление интерфейса и перевод остальных текстов


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


Проблемы и решения в непрерывной локализации


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


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


Небольшие по объему регулярные переводы частое лучше делать с помощью профессионального программного обеспечения (не прибегая к машинному переводу). К примеру, с помощью нашего сервиса для перевода текстов Nitro можно получить профессиональный перевод в течение нескольких часов.



Интеграция программного обеспечения для управления переводами


Ключевое, удобное для компаний решение это использование программного обеспечения для переводов, с которым работают специалисты по локализации. Такой софт, как правило, интегрируется с веб-сайтами и платформами компании посредством API или CLI.


А ещё на таких платформах менеджеры по продукту, специалисты по локализации и переводчики получают уведомления, когда необходимо перевести новую строку (слово, фразу, абзац). И затем либо сразу приступают к переводу (если есть такая договоренность), либо ждут, когда будет назначено задание.


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


Оценка качества


Наконец, можно реализовать частые проверки качества в форме лингвистического тестирования, что позволит улучшить продукт и его восприятие пользователями.


Лингвистическое тестирование это когда специалист по локализации тестирует сборку на соответствующей локальной версии ОС. При этом делаются снимки экрана с проблемами (непереведенный текст, не влезающие в экран строки, неправильные кодировка, направление текста или контекст) и с помощью разработчиков вносятся изменения в ресурсные файлы.


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


Нужна помощь с локализацией / переводом? Мы в Alconost всегда рады помочь!


О нас


Alconost профессионально занимается локализацией игр, приложений и сайтов на более 70 языков. Лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджмент проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем видеоролики.
Подробнее

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru