KF5 version: git master from a few days ago There seems to be a problem with how the translationDomain attribute in top tag is merged. I read the source code (mostly KXmlGuiWindow::createGUI and functions called from there, like KXMLGUIFactory::addClient) and the following seems to happen: 1. rc file for xmlgui itself is loaded and contains translationDomain "kxmlgui5". 2. rc file for an application (no translationDomain attribute) is loaded and then it is merged with xmlgui's rc file. 3. Now there is one merged rc document that has translationDomain "kxmlgui5" 4. Menu and action names are translated using the translationDomain "kxmlgui5" Thus, the information about an empty translation domain is lost. There is also another variation if translationDomain attribute is set for the rc file of the first client (for example "fooapp"), the file that other clients are merged onto. That is: 1. rc file for xmlgui itself is loaded and contains translationDomain "kxmlgui5". 2. The first client rc file (with translationDomain "fooapp") is loaded and then it is merged with xmlgui's rc file. 3. Now there is one merged rc document that has translationDomain "fooapp" 4. Menu and action names are translated using the translationDomain "fooapp", including those that come from kxmlgui5's standard rc file. Reproducible: Always Steps to Reproduce: 1. Compile and install for example KF5-based Gwenview. 2. Start Gwenview using x-test. Actual Results: On the menu bar, the Plugins menu isn't translated. Expected Results: The Plugins menu is translated because application domain is set to "gwenview" in gwenview/app/main.cpp and "&Plugins" exists in gwenviewui.rc.
Confirmed in recent build. I my debug output I see a query for "&Plugins" from domain kxmlgui5, but the domain should be gwenview. http://api.kde.org/frameworks-api/frameworks5-apidocs/ki18n/html/prg_guide.html#link_noncode says: If the .rc file belongs to application rather than library source, it is not necessary to set translationDomain. If not set, translations will be looked up in the domain set with KLocalizedString::setApplicationDomain call in the code. That does apparently not work as described. I have to add translationDomain="gwenview" translationMarkup="true" to the header of app/gwenviewui.rc to get the translation of Plugins in the GUI. Adding Chuslove to clarify this issue.
Hm, yes, this merging stuff is pretty much ruining the idea. The solution then is to modify KXmlGui to propagate the translationDomain attribute from the top element to all text-containing subelements, as soon as an .rc file is loaded. Then internal merging can proceed as it is, as domain will be taken from current subelement, and not top. I'll see to it these days...
Git commit 2920e946c24d78eb0b6b3038a9cc38a8897ce4ac by Chusslove Illich (Часлав Илић). Committed on 18/03/2015 at 12:28. Pushed by ilic into branch 'master'. Preserve translation domain when merging .rc files When two .rc documents that specify different translation domains are merged, only one of the two domains will appear in the merged document. This breaks translation of text elements under the dropped domain. To fix it, the top domain attribute (or the application domain) is now propagated to each text element before merging. Then, at the moment of translation, the local domain attribute takes priority over the top attribute (or the application domain). REVIEW: 122937 M +5 -2 src/kedittoolbar.cpp M +2 -0 src/kpartgui.dtd M +7 -2 src/ktoolbar.cpp M +4 -1 src/kxmlgui.xsd M +10 -4 src/kxmlguibuilder.cpp M +36 -0 src/kxmlguiclient.cpp http://commits.kde.org/kxmlgui/2920e946c24d78eb0b6b3038a9cc38a8897ce4ac