Почему люди используют i18n() и i18nc() вместо qsTr()?
Я совершенно новичок в переводе виджетов QML. Я вижу людей, использующих i18n() и i18nc() в своем исходном коде. Я нашел команды, задокументированные здесь:
https://techbase.kde.org/Development/Tutorials/Localization/i18n
Но в документации QML перечислен только метод qsTr(). Я предполагаю, что другие 2 команды специфичны для KDE?
Должен ли я в действительности баловаться с этими объектами KDeclarative и т. Д. В C++? Я не совсем уверен, как это работает. Мой виджет не использует ничего из этого, только файлы qml и некоторые файлы javascript для внешних функций.
Я обнаружил, что могу заставить перевод работать с PoEdit, но только для файлов.js, если я определю пользовательское ключевое слово источника (имя функции) для извлечения из них, и ТОЛЬКО если они i18n и i18nc (qsTr не работать) и при использовании структуры каталогов я украл из рабочего виджета (то есть / contents / locale / language_key / plasma_applet_widget_id.mo). К сожалению, поскольку синтаксический анализатор getText не может читать файлы qml, это решение недостаточно хорошо.
Теперь я знаю, что qt предоставляет команду lupdate для извлечения этих ключевых слов из источника, но, наоборот, это работает только для qsTr. Попытка передать -tr-function-alias qsTr=(i18n) в качестве аргумента не работает. С qsTr() у меня может быть хороший файл.ts, но попытка преобразовать его в po и использовать ранее упомянутый трюк не работает.
Интересно, почему разработчики загружаемых виджетов, кажется, используют i18n и i18nc в своем исходном коде, если lupdate не может извлечь эти ключевые слова.
1 ответ
Почему люди используют i18n и i18nc вместо qsTr? Наверное, потому что это намного удобнее. Я смог заставить файлы.qml работать, используя вышеупомянутый трюк, просто вручную редактируя файлы.po (ссылаясь на рассматриваемый файл qml, строку, где встречается ключевое слово, и т. Д.).