Set up the translation domain automatically for click packages
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu UI Toolkit |
Fix Released
|
Undecided
|
Cris Dywan | ||
ubuntu-ui-toolkit (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Right now, the i18n plugin is initialized automatically for QML apps in the sense that i18n.domain is set to the name of the app and i18n.textdomain is set to /usr/share/locale. This way developers can start using the i18n system straight away without having to worry to initialize it (which they can nevertheless do, if they want to override the default settings).
However, with click packages the i18n.textdomain assumption does no longer hold true, as the translations will not be installed in the system locations.
For click packages, i18n.textdomain should be set to @{CLICK_
Note: the last statement should be double-checked with the security team. The requirement for gettext to work is that the folder hierarchy under locale/ stays the same as the layout in /usr/share/locale, but the prefix can be any specified as i18n.textdomain.
Related branches
- PS Jenkins bot: Approve (continuous-integration)
- Tim Peeters: Approve
-
Diff: 444 lines (+270/-75)8 files modifieddebian/control (+2/-0)
modules/Ubuntu/Components/plugin/i18n.cpp (+29/-6)
tests/unit/tst_components/tst_plugin_i18n.qml (+0/-69)
tests/unit/tst_i18n/po/en_US.po (+17/-0)
tests/unit/tst_i18n/src/LocalizedApp.qml (+35/-0)
tests/unit/tst_i18n/src/tst_i18n.cpp (+175/-0)
tests/unit/tst_i18n/tst_i18n.pro (+11/-0)
tests/unit/unit.pro (+1/-0)
tags: | added: i18n |
tags: | added: application-confinement |
description: | updated |
description: | updated |
description: | updated |
Changed in ubuntu-ui-toolkit: | |
assignee: | nobody → Christian Dywan (kalikiana) |
status: | New → In Progress |
summary: |
- Set up the translation domain automatically for click packages + 设置自动翻译域点击包 |
summary: |
- 设置自动翻译域点击包 + Set up the translation domain automatically for click packages |
@{CLICK_ DIR}/@{ APP_PKGNAME} /@{APP_ VERSION} corresponds to the install directory of the click app, so using @{CLICK_ DIR}/@{ APP_PKGNAME} /@{APP_ VERSION} /locale is just fine from a security POV and wrt apparmor policy.
That said, upstream click has been clear that people should not hard code paths to the @{CLICK_DIR} because @{CLICK_DIR} is configurable and subject to change. I'm not sure what the solution is-- though I can say that both upstart-app-launch and aa-exec-click will chdir to the install directory (the Path= in the .desktop file), so perhaps a relative path can be used instead. I suggest talking to the click team for input.