Почему люди используют i18n () и i18nc () вместо qsTr ()? - PullRequest
0 голосов
/ 28 октября 2018

Я совершенно новичок в переводе виджетов QML.Я вижу людей, использующих i18n () и i18nc () в своем исходном коде.Я нашел команды, задокументированные здесь:

https://techbase.kde.org/Development/Tutorials/Localization/i18n#QML

Но в документации 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 Ответ

0 голосов
/ 29 октября 2018

Почему люди используют i18n и i18nc вместо qsTr?Наверное, потому что это намного удобнее.Мне удалось заставить файлы .qml работать, используя вышеупомянутый прием, просто вручную отредактировав файлы .po (ссылаясь на рассматриваемый файл qml, строку, где находится ключевое слово, и т. Д.).

...