人们为什么使用i18n()和i18nc()而不是qsTr()?

时间:2018-10-28 13:11:23

标签: localization qml kde kde-plasma

我对翻译QML小部件是完全陌生的。 我看到人们在他们的源代码中使用i18n()和i18nc()。 我发现这里记录了命令:

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

但是QML文档只列出了qsTr()方法。我猜其他2个命令是KDE特定的?

我真的必须涉猎那些C ++中的KDeclarative etc对象吗?我不确定这是如何工作的。我的窗口小部件不使用其中任何一个,仅使用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并使用前面提到的技巧是行不通的。

我想知道,如果lupdate似乎无法提取那些关键字,为什么可下载窗口小部件的开发人员似乎都在源代码中使用i18n和i18nc。

1 个答案:

答案 0 :(得分:1)

为什么人们使用i18n和i18nc代替qsTr? 可能是因为它更方便。通过简单地手动编辑.po文件(引用有问题的qml文件,出现关键字的行等等),我已经能够使用上述技巧使.qml文件起作用。