Re: desktoptojson and list properties / i18n of JSON files
On Thursday, November 20, 2014 20:18:29 Burkhard Lück wrote: Am Donnerstag, 20. November 2014, 20:05:19 schrieb Sebastian Kügler: On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. The json embedded in plugins is created using the desktoptojson tool. This tool runs at build time, it converts a .desktop file (including its translations) to a .json file, which is then embedded into the plugin binary. This tool has only limited understanding of list properties (this limitation is what Milian's problem triggering this thread is about). An idea is to not do a conversion, but rather add a json file to the repository, which can directly be included. Since translations are done in the .desktop file, the json file would not be translated. This is the root of the problem. Please launch LANGUAGE=nl kdevelop or LANGUAGE=nl kate in Konsole. Do you have translated Names/Description in the settings dialog page Plugins? Again, and sorry for not making myself clear, this problem is only secondary about translations, it's mainly about the metadata in the plugins being wrong for custom keys that use a list, i.e. QStringLists. Fixing localization in kdevelop is really a different issue -- not less important, just different. cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
Am Freitag, 21. November 2014, 00:16:23 schrieben Sie: On Friday 21 November 2014 00:07:53 Milian Wolff wrote: On Thursday 20 November 2014 19:57:54 Burkhard Lück wrote: Am Mittwoch, 19. November 2014, 23:00:57 schrieb Albert Astals Cid: Well, there's two steps about this: 1) Know where the code is that gets the Name/Comment/Description from the json 2) Decide how you want to translate stuff (which may depend on 1) For 2) there's broadly two options: 2.1: Make the .json file have the translations and make sure the code from 1 reads it properly 2.2: Make the translations be in the .po and then make the code from 1 read the english variant and call i18n(englishText) 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. OK, that sounds good and that is also what I hoped was already the case. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. I have played a bit with pythons json module using kdevpatchreview.json and the following workflow might be possible: * Find all *json in a repo * generate a template json_reponame.pot with all translatable strings from all json files in the repo (msgid=string, msgctxt=dictkeyofstring+jsonfilename to get unique translations per file or similar) * translators translate these json_reponame.pos and Scripty merges the translation back in to the *.json in the repos similar to merging back translations of xml mimetype translations. *This* is what I was wondering about. If no .desktop exists in the first place and we just create a .json, will translators be able to translate it? Many thanks for looking into that, it sounds as if you don't need more help from my side? If there is anything I can do, please tell me. snip Since Albert just asked me about that: Burkhard, I understood your sentence above such, that you already have code to implement the workflow you outline above. I'll file a RR to implement extraction of translations in json files into scripty's workflow later and add you as reviewer. As first step let's make the extraction working properly, especially with the new json files you have in mind. If that works as expected we can add updating translations in json files. If that is not the case, I'll be happy to implement it for you. If that is the case, can you give me some directions as to where the code resides that does the xml mimetype translations? trunk/l10n-kf5/scripts: update_translations is the main script extract-xml.sh - extract mimetype translation to pot fillxmlfrompo.py - spreading mimetype translations into mimetype xml files, but for json translations the workflow has to be different: 1) load each json into a python dict 2) throw away any translation 3) add all translations from svn po's 4) write python dict to json file create_desktop_files.sh + createdesktopcontext.pl for desktop file translation Also maybe where/how I can run the *.desktop - *.pot conversion manually, such that I can test compare it against my future *.json - *.pot code? I'd say we should use kdevelop or kdevplatform as guinea pig, means you add your future json files (without using them in the code actually) and will check if the templates generated by scripty are ok and adapt the extraction as necessary. Albert? Manually I have used my local kdevplatform build dir for testing: l10n-kf5/scripts$ python createjsoncontext.py $(find ../../extragear/build/kdevelop_kdevplatform/ -name *.json) ../../extragear/build/ /tmp//json_kdevplatform.pot Thanks. -- Burkhard Lück
Re: desktoptojson and list properties / i18n of JSON files
On Thu, Nov 20, 2014 at 8:47 AM, Burkhard Lück lu...@hube-lueck.de wrote: Am Mittwoch, 19. November 2014, 18:46:28 schrieben Sie: So again, what is necessary to get this done? First step is to make kdevelop in kf5 translatable using the normal po files, then let's talk about json translation: * KDevelop has 20 translation catalogs, but none of them is used (no setApplicationDomain call, no TRANSLATION_DOMAIN defintion) * KDevelop uses ki18n (XGETTEXT) and qt5_wrap_ui. That is broken, a ki18n based system has to use ki18n_wrap_ui * KDevelop has 9 .rc files, 6 of them do not belong to an application with a KLocalizedString::setApplicationDomain call, therefore these 6 rc files need a translationDomain definition of the corresponding translation catalog in the header. * KDevplatform has 32 translation catalogs, but only one add_definitions(- DTRANSLATION_DOMAIN=\kdevplatform\) line in the top level CMakeLists file - translations in 31 catalogs are not used. * KDevplatform uses ki18n (XGETTEXT) and qt5_wrap_ui. That is broken, a ki18n based system has to use ki18n_wrap_ui * KDevplatform has 21 .rc files, none of them belongs to an application with a KLocalizedString::setApplicationDomain call, therefore all of them need a translationDomain definition of the corresponding translation catalog in the header. -- Burkhard Lück Hi Burkhard, While I appreciate your research on the list of things we are doing wrong, I think this is completely out of place. KDE is clearly relying on a half-baked technology that must be either fixed or get a replacement. That's what Milian is saying here. In fact, the current situation is so broken we can't adopt the technology (KPluginMetaData). The fact that you point out that we have also other problems to fix, while Milian is annoying you by offering to help for the greater good is odd. Aleix
Re: desktoptojson and list properties / i18n of JSON files
Am Mittwoch, 19. November 2014, 18:46:28 schrieben Sie: On Wednesday 19 November 2014 17:30:28 Burkhard Lück wrote: Am Mittwoch, 19. November 2014, 01:28:51 schrieb Kevin Funk: On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. But the kdevpatchreview.desktop is installed nevertheless and is apparently used to get the translations for Name + Comment/Description. Having german translations for Name + Comment/Description only in kdevpatchreview.json at build time, but removed after installation in the installed kdevpatchreview.desktop file makes them untranslated for me. This was from kde4, kf5 apparently is different. And if the .desktop is not installed at all (we do this in other places, and would/should do it here too). Are translations then gone alltogether? One more reason to get i18n support for .json files. In kde4 the plugin is gone without a desktop file. Looks to me like translations are not supported via json files. That is only true for kde4 Please check the above. Anyhow, imo it should be our goal to get this supported. In the ideal scenario, a plugin would be just a .so installed into the right directory. No .desktop, no sycoca cache. So again, what is necessary to get this done? See my other mail in this thread. -- Burkhard Lück
Re: desktoptojson and list properties / i18n of JSON files
Am Mittwoch, 19. November 2014, 23:00:57 schrieb Albert Astals Cid: Well, there's two steps about this: 1) Know where the code is that gets the Name/Comment/Description from the json 2) Decide how you want to translate stuff (which may depend on 1) For 2) there's broadly two options: 2.1: Make the .json file have the translations and make sure the code from 1 reads it properly 2.2: Make the translations be in the .po and then make the code from 1 read the english variant and call i18n(englishText) 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. I have played a bit with pythons json module using kdevpatchreview.json and the following workflow might be possible: * Find all *json in a repo * generate a template json_reponame.pot with all translatable strings from all json files in the repo (msgid=string, msgctxt=dictkeyofstring+jsonfilename to get unique translations per file or similar) * translators translate these json_reponame.pos and Scripty merges the translation back in to the *.json in the repos similar to merging back translations of xml mimetype translations. -- Burkhard Lück
Re: desktoptojson and list properties / i18n of JSON files
On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. The json embedded in plugins is created using the desktoptojson tool. This tool runs at build time, it converts a .desktop file (including its translations) to a .json file, which is then embedded into the plugin binary. This tool has only limited understanding of list properties (this limitation is what Milian's problem triggering this thread is about). An idea is to not do a conversion, but rather add a json file to the repository, which can directly be included. Since translations are done in the .desktop file, the json file would not be translated. This is the root of the problem. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
Am Donnerstag, 20. November 2014, 20:05:19 schrieb Sebastian Kügler: On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. The json embedded in plugins is created using the desktoptojson tool. This tool runs at build time, it converts a .desktop file (including its translations) to a .json file, which is then embedded into the plugin binary. This tool has only limited understanding of list properties (this limitation is what Milian's problem triggering this thread is about). An idea is to not do a conversion, but rather add a json file to the repository, which can directly be included. Since translations are done in the .desktop file, the json file would not be translated. This is the root of the problem. Please launch LANGUAGE=nl kdevelop or LANGUAGE=nl kate in Konsole. Do you have translated Names/Description in the settings dialog page Plugins? -- Burkhard Lück
Re: desktoptojson and list properties / i18n of JSON files
El Dijous, 20 de novembre de 2014, a les 20:18:29, Burkhard Lück va escriure: Am Donnerstag, 20. November 2014, 20:05:19 schrieb Sebastian Kügler: On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. The json embedded in plugins is created using the desktoptojson tool. This tool runs at build time, it converts a .desktop file (including its translations) to a .json file, which is then embedded into the plugin binary. This tool has only limited understanding of list properties (this limitation is what Milian's problem triggering this thread is about). An idea is to not do a conversion, but rather add a json file to the repository, which can directly be included. Since translations are done in the .desktop file, the json file would not be translated. This is the root of the problem. Please launch LANGUAGE=nl kdevelop or LANGUAGE=nl kate in Konsole. Do you have translated Names/Description in the settings dialog page Plugins? Yes they are translated, but this is tangential to the issue here, they are translated because the .desktop file is converted to .json on compile time and then embedded into the .so file of the plugin. What Milian wants is not having the .desktop file in the repository, but having the .json file directly, it's an unneeded conversion step if we have the proper i18n tooling for it. Cheers, Albert
Re: desktoptojson and list properties / i18n of JSON files
Am Donnerstag, 20. November 2014, 22:55:03 schrieb Albert Astals Cid: El Dijous, 20 de novembre de 2014, a les 20:18:29, Burkhard Lück va escriure: Am Donnerstag, 20. November 2014, 20:05:19 schrieb Sebastian Kügler: On Thursday, November 20, 2014 19:57:54 Burkhard Lück wrote: 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. The json embedded in plugins is created using the desktoptojson tool. This tool runs at build time, it converts a .desktop file (including its translations) to a .json file, which is then embedded into the plugin binary. This tool has only limited understanding of list properties (this limitation is what Milian's problem triggering this thread is about). An idea is to not do a conversion, but rather add a json file to the repository, which can directly be included. Since translations are done in the .desktop file, the json file would not be translated. This is the root of the problem. Please launch LANGUAGE=nl kdevelop or LANGUAGE=nl kate in Konsole. Do you have translated Names/Description in the settings dialog page Plugins? Yes they are translated, but this is tangential to the issue here, they are translated because the .desktop file is converted to .json on compile time and then embedded into the .so file of the plugin. What Milian wants is not having the .desktop file in the repository, but having the .json file directly, it's an unneeded conversion step if we have the proper i18n tooling for it. Kate and KDevelop do not install any desktop file in kf5 so we can skip the conversion of deskop to json files and start to translate json files directly. -- Burkhard Lück
Re: desktoptojson and list properties / i18n of JSON files
2014-11-19 16:30 GMT+00:00 Burkhard Lück lu...@hube-lueck.de: Am Mittwoch, 19. November 2014, 01:28:51 schrieb Kevin Funk: On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. But the kdevpatchreview.desktop is installed nevertheless and is apparently used to get the translations for Name + Comment/Description. Having german translations for Name + Comment/Description only in kdevpatchreview.json at build time, but removed after installation in the installed kdevpatchreview.desktop file makes them untranslated for me. Looks to me like translations are not supported via json files. Translations are definitively supported with the JSON metadata. kdevpatchreview.desktop is not installed, seems that is a leftover from an older make install. I guess the .desktop file overrides the metadata loaded from the .so file. They both have the same plugin id so the one that is added later (.desktop) overrides the previous one. Regards, Alex
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 18:46:28 Milian Wolff wrote: Looks to me like translations are not supported via json files. Please check the above. Anyhow, imo it should be our goal to get this supported. In the ideal scenario, a plugin would be just a .so installed into the right directory. No .desktop, no sycoca cache. That's exactly the idea. The json metadata baked into the plugin should have all necessary information, in the right form (so also the list properties Milian started this thread about) and be translatable . This ultimately allows us to get rid of installing desktop files, and plugins just become one single file (the .so file), instead of an .so file and a .desktop file in two different places. So again, what is necessary to get this done? A translation expert / i18n dude should be able to answer this, I know too little about translations. :/ Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 23:00:57 Albert Astals Cid wrote: So again, what is necessary to get this done? Well, there's two steps about this: 1) Know where the code is that gets the Name/Comment/Description from the json I don't understand this. What do you mean exactly? 2) Decide how you want to translate stuff (which may depend on 1) For 2) there's broadly two options: 2.1: Make the .json file have the translations and make sure the code from 1 reads it properly 2.2: Make the translations be in the .po and then make the code from 1 read the english variant and call i18n(englishText) 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. I'd prefer 2.1, since we have to write the json metadata into the plugins, so we'd have to assemble the original (untranslated) and translated data into one json structure anyway. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 18:46:28 Milian Wolff wrote: Looks to me like translations are not supported via json files. Please check the above. Anyhow, imo it should be our goal to get this supported. In the ideal scenario, a plugin would be just a .so installed into the right directory. No .desktop, no sycoca cache. That's exactly the idea. The json metadata baked into the plugin should have all necessary information, in the right form (so also the list properties Milian started this thread about) and be translatable . This ultimately allows us to get rid of installing desktop files, and plugins just become one single file (the .so file), instead of an .so file and a .desktop file in two different places. So again, what is necessary to get this done? A translation expert / i18n dude should be able to answer this, I know too little about translations. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday, November 19, 2014 23:00:57 Albert Astals Cid wrote: So again, what is necessary to get this done? Well, there's two steps about this: 1) Know where the code is that gets the Name/Comment/Description from the json I don't understand this. What do you mean exactly? 2) Decide how you want to translate stuff (which may depend on 1) For 2) there's broadly two options: 2.1: Make the .json file have the translations and make sure the code from 1 reads it properly 2.2: Make the translations be in the .po and then make the code from 1 read the english variant and call i18n(englishText) 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. I'd prefer 2.1, since we have to write the json metadata into the plugins, so we'd have to assemble the original (untranslated) and translated data into one json structure anyway. Cheers, -- sebas Sebastian Kügler|http://vizZzion.org| http://kde.org
Re: desktoptojson and list properties / i18n of JSON files
On Thursday 20 November 2014 19:57:54 Burkhard Lück wrote: Am Mittwoch, 19. November 2014, 23:00:57 schrieb Albert Astals Cid: Well, there's two steps about this: 1) Know where the code is that gets the Name/Comment/Description from the json 2) Decide how you want to translate stuff (which may depend on 1) For 2) there's broadly two options: 2.1: Make the .json file have the translations and make sure the code from 1 reads it properly 2.2: Make the translations be in the .po and then make the code from 1 read the english variant and call i18n(englishText) 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. In kf5 using LANGUAGE=foo kate or LANGUAGE=foo kdevelop (both projects do not install desktop files but use json files generated at build time from desktop files) I see the name/description (from the json files) of plugins in the settings dialog translated in language foo. So apparently in kf5 using json files with translated Name/Description as provided by Kevin's example kdevpatchreview.json I get the proper translations in the GUI. Please check that, you do not need to have language foo installed, just launch kate or kdevelop using x-test/uk/de/fr... as value for foo. OK, that sounds good and that is also what I hoped was already the case. If that works we could treat json and desktop files in the same way from devel/translators pov, because what is the difference between desktop and json files? Name and format, nothing else. I have played a bit with pythons json module using kdevpatchreview.json and the following workflow might be possible: * Find all *json in a repo * generate a template json_reponame.pot with all translatable strings from all json files in the repo (msgid=string, msgctxt=dictkeyofstring+jsonfilename to get unique translations per file or similar) * translators translate these json_reponame.pos and Scripty merges the translation back in to the *.json in the repos similar to merging back translations of xml mimetype translations. *This* is what I was wondering about. If no .desktop exists in the first place and we just create a .json, will translators be able to translate it? Many thanks for looking into that, it sounds as if you don't need more help from my side? If there is anything I can do, please tell me. In general though, I'd say we should not blindly translate all *.json files in the repository. Rather, lets come up with a more specific extension filter. What about *.i18n.json? I fear that using *.json is too generic and will lead to manual work to exclude *.json files that are not supposed to be translated. We didn't have this issue before since all *.desktop files are supposed to be translated. Bye, and many thanks again - also to your patches and inspection of the i18n issues in our KF5 port. We were really not aware of that at all. I'll try to go through your list over the weekend. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: desktoptojson and list properties / i18n of JSON files
Am Mittwoch, 19. November 2014, 01:28:51 schrieb Kevin Funk: On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. But the kdevpatchreview.desktop is installed nevertheless and is apparently used to get the translations for Name + Comment/Description. Having german translations for Name + Comment/Description only in kdevpatchreview.json at build time, but removed after installation in the installed kdevpatchreview.desktop file makes them untranslated for me. Looks to me like translations are not supported via json files. -- Burkhard Lück
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday 19 November 2014 17:30:28 Burkhard Lück wrote: Am Mittwoch, 19. November 2014, 01:28:51 schrieb Kevin Funk: On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. But the kdevpatchreview.desktop is installed nevertheless and is apparently used to get the translations for Name + Comment/Description. Having german translations for Name + Comment/Description only in kdevpatchreview.json at build time, but removed after installation in the installed kdevpatchreview.desktop file makes them untranslated for me. And if the .desktop is not installed at all (we do this in other places, and would/should do it here too). Are translations then gone alltogether? One more reason to get i18n support for .json files. Looks to me like translations are not supported via json files. Please check the above. Anyhow, imo it should be our goal to get this supported. In the ideal scenario, a plugin would be just a .so installed into the right directory. No .desktop, no sycoca cache. So again, what is necessary to get this done? Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: desktoptojson and list properties / i18n of JSON files
El Dimecres, 19 de novembre de 2014, a les 18:46:28, Milian Wolff va escriure: On Wednesday 19 November 2014 17:30:28 Burkhard Lück wrote: Am Mittwoch, 19. November 2014, 01:28:51 schrieb Kevin Funk: On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. But the kdevpatchreview.desktop is installed nevertheless and is apparently used to get the translations for Name + Comment/Description. Having german translations for Name + Comment/Description only in kdevpatchreview.json at build time, but removed after installation in the installed kdevpatchreview.desktop file makes them untranslated for me. And if the .desktop is not installed at all (we do this in other places, and would/should do it here too). Are translations then gone alltogether? One more reason to get i18n support for .json files. Looks to me like translations are not supported via json files. Please check the above. Anyhow, imo it should be our goal to get this supported. In the ideal scenario, a plugin would be just a .so installed into the right directory. No .desktop, no sycoca cache. So again, what is necessary to get this done? Well, there's two steps about this: 1) Know where the code is that gets the Name/Comment/Description from the json 2) Decide how you want to translate stuff (which may depend on 1) For 2) there's broadly two options: 2.1: Make the .json file have the translations and make sure the code from 1 reads it properly 2.2: Make the translations be in the .po and then make the code from 1 read the english variant and call i18n(englishText) 2.2 is easier (if possible to change the code in 1 to do it) since it does not involve writing back strings to the json file. Cheers, Albert Bye
Re: desktoptojson and list properties / i18n of JSON files
Am Mittwoch, 19. November 2014, 18:46:28 schrieben Sie: So again, what is necessary to get this done? First step is to make kdevelop in kf5 translatable using the normal po files, then let's talk about json translation: * KDevelop has 20 translation catalogs, but none of them is used (no setApplicationDomain call, no TRANSLATION_DOMAIN defintion) * KDevelop uses ki18n (XGETTEXT) and qt5_wrap_ui. That is broken, a ki18n based system has to use ki18n_wrap_ui * KDevelop has 9 .rc files, 6 of them do not belong to an application with a KLocalizedString::setApplicationDomain call, therefore these 6 rc files need a translationDomain definition of the corresponding translation catalog in the header. * KDevplatform has 32 translation catalogs, but only one add_definitions(- DTRANSLATION_DOMAIN=\kdevplatform\) line in the top level CMakeLists file - translations in 31 catalogs are not used. * KDevplatform uses ki18n (XGETTEXT) and qt5_wrap_ui. That is broken, a ki18n based system has to use ki18n_wrap_ui * KDevplatform has 21 .rc files, none of them belongs to an application with a KLocalizedString::setApplicationDomain call, therefore all of them need a translationDomain definition of the corresponding translation catalog in the header. -- Burkhard Lück
Re: desktoptojson and list properties
On Monday, November 17, 2014 18:50:04 Milian Wolff wrote: Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. So scripty and the ki18n crew can cope with .json files nowadays? No reason to use .desktop at all anymore? That would be an acceptable solution for me. Though I guess desktoptojson should get a big fat warning that this it is deprecated and one should better write .json directly to prevent such issues from occurring randomly in other projects. Had I read your email, I'd have said no. I don't think scripty is ready for that yet, and desktoptojson isn't deprecated (and I doubt it will be for some time). -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: desktoptojson and list properties / i18n of JSON files
On Tuesday 18 November 2014 12:48:42 Sebastian Kügler wrote: On Monday, November 17, 2014 18:50:04 Milian Wolff wrote: Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. So scripty and the ki18n crew can cope with .json files nowadays? No reason to use .desktop at all anymore? That would be an acceptable solution for me. Though I guess desktoptojson should get a big fat warning that this it is deprecated and one should better write .json directly to prevent such issues from occurring randomly in other projects. Had I read your email, I'd have said no. I don't think scripty is ready for that yet, and desktoptojson isn't deprecated (and I doubt it will be for some time). Criss-cross! So back to the start. What can we do about this? Since this is a serious blocker for KDevelop, I'm open for suggestions and would be willing to spent time on improving the situation. What blocks i18n from working on JSON files, does anyone know more about this? I think fixing that would be time well spent, contrary to improving desktoptojson. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: desktoptojson and list properties / i18n of JSON files
El Dimarts, 18 de novembre de 2014, a les 14:09:00, Milian Wolff va escriure: On Tuesday 18 November 2014 12:48:42 Sebastian Kügler wrote: On Monday, November 17, 2014 18:50:04 Milian Wolff wrote: Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. So scripty and the ki18n crew can cope with .json files nowadays? No reason to use .desktop at all anymore? That would be an acceptable solution for me. Though I guess desktoptojson should get a big fat warning that this it is deprecated and one should better write .json directly to prevent such issues from occurring randomly in other projects. Had I read your email, I'd have said no. I don't think scripty is ready for that yet, and desktoptojson isn't deprecated (and I doubt it will be for some time). Criss-cross! So back to the start. What can we do about this? Since this is a serious blocker for KDevelop, I'm open for suggestions and would be willing to spent time on improving the situation. What blocks i18n from working on JSON files, does anyone know more about this? I think fixing that would be time well spent, contrary to improving desktoptojson. Why do we need i18n support in json files? Cheers, Albert Bye
Re: desktoptojson and list properties / i18n of JSON files
On Tuesday 18 November 2014 22:31:08 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 14:09:00, Milian Wolff va escriure: On Tuesday 18 November 2014 12:48:42 Sebastian Kügler wrote: On Monday, November 17, 2014 18:50:04 Milian Wolff wrote: Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. So scripty and the ki18n crew can cope with .json files nowadays? No reason to use .desktop at all anymore? That would be an acceptable solution for me. Though I guess desktoptojson should get a big fat warning that this it is deprecated and one should better write .json directly to prevent such issues from occurring randomly in other projects. Had I read your email, I'd have said no. I don't think scripty is ready for that yet, and desktoptojson isn't deprecated (and I doubt it will be for some time). Criss-cross! So back to the start. What can we do about this? Since this is a serious blocker for KDevelop, I'm open for suggestions and would be willing to spent time on improving the situation. What blocks i18n from working on JSON files, does anyone know more about this? I think fixing that would be time well spent, contrary to improving desktoptojson. Why do we need i18n support in json files? Same reason we have i18n support for .desktop files. KPluginMetaData or what its called uses that e.g. to show the localized names of plugins etc., no? Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: desktoptojson and list properties / i18n of JSON files
El Dimarts, 18 de novembre de 2014, a les 23:35:48, Milian Wolff va escriure: On Tuesday 18 November 2014 22:31:08 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 14:09:00, Milian Wolff va escriure: On Tuesday 18 November 2014 12:48:42 Sebastian Kügler wrote: On Monday, November 17, 2014 18:50:04 Milian Wolff wrote: Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. So scripty and the ki18n crew can cope with .json files nowadays? No reason to use .desktop at all anymore? That would be an acceptable solution for me. Though I guess desktoptojson should get a big fat warning that this it is deprecated and one should better write .json directly to prevent such issues from occurring randomly in other projects. Had I read your email, I'd have said no. I don't think scripty is ready for that yet, and desktoptojson isn't deprecated (and I doubt it will be for some time). Criss-cross! So back to the start. What can we do about this? Since this is a serious blocker for KDevelop, I'm open for suggestions and would be willing to spent time on improving the situation. What blocks i18n from working on JSON files, does anyone know more about this? I think fixing that would be time well spent, contrary to improving desktoptojson. Why do we need i18n support in json files? Same reason we have i18n support for .desktop files. KPluginMetaData or what its called uses that e.g. to show the localized names of plugins etc., no? I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Sorry to ask old-man questions :D Cheers, Albert Bye
Re: desktoptojson and list properties / i18n of JSON files
On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). Alex
Re: desktoptojson and list properties / i18n of JSON files
El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Cheers, Albert Alex
Re: desktoptojson and list properties / i18n of JSON files
On Wednesday 19 November 2014 00:09:25 Albert Astals Cid wrote: El Dimarts, 18 de novembre de 2014, a les 23:01:14, Alex Merry va escriure: On Tuesday 18 November 2014 23:45:56 Albert Astals Cid wrote: I didn't even know we were using json now. Why did we change from .desktop file to .json ones? What's the benefit? Seems like .desktop files did their job good enough and we have all the tooling available already. Because that's what Qt uses - Qt5 plugins have JSON metadata as standard, meaning it's all in one file (the JSON is embedded in the plugin, although it can be read without loading the plugin). And Qt introduced a technology without making it translatable? What fields do we need to make translatable? Can somebody point me to such a .json file we'd like to translate? Here's one: http://pastebin.kde.org/p4p38fqr1 That's kdevpatchreview.json, generated from kdevpatchreview.desktop via kcoreaddons_desktop_to_json(...) during the CMake run. Cheers -- Kevin Funk | kf...@kde.org | http://kfunk.org
Re: desktoptojson and list properties
On Monday, November 17, 2014 02:04:51 Aleix Pol wrote: On Mon, Nov 17, 2014 at 12:24 AM, Milian Wolff m...@milianw.de wrote: On Sunday 16 November 2014 23:52:25 Milian Wolff wrote: KDevelop is currently bitten hard by a bug/limitation in desktoptojson. It does not actually understand the .desktop files and custom properties get converted to plain JSON strings. Looking at the sources it's also clear why, only a selected list of .desktop properties is interpreted as lists. We have a custom kdevelopplugin.desktop file that describes our custom properties via something like: [Desktop Entry] Type=ServiceType X-KDE-ServiceType=KDevelop/Plugin X-KDE-Derived=KPluginInfo Name=KDevelop Plugin ... [PropertyDef::X-KDevelop-Interfaces] Type=QStringList ... To me it looks like I'll have to add support for such files to desktoptojson. But I wonder: Where was/is the code for the above files (how are they called?)? Apparently these are KServiceType's and the code can be found in kservice. In kservice.cpp's KServicePrivate::property we see code like this: // No luck, let's ask KServiceTypeFactory what the type of this property // is supposed to be. // # this looks in all servicetypes, not just the ones this service // supports! KServiceTypeFactory::self()-findPropertyTypeByName(...) You can't do this, desktoptojson is in kcoreaddons nowadays, and doesn't allow KService as a dependency. Currently, the list properties are hardcoded in desktoptojson. I suppose you could also add it in there, but that feels quite meh, since ... well... hardcoded. Fine, I could add similar code to desktoptojson, but: Since desktoptojson will be called for the plugins we ship in KDevplatform, how would/could I make desktoptojson know about the kdevelopplugin.desktop file without it being installed yet? that would not work here as our service type is still unknown to kbuildsycoca! Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. I guess a solution would be to be able to provide the servicetype file as an argument to desktoptojson? Also given how the plan is to move away from kbuildsycoca database for these files (no?) maybe it would make sense to have an alternative way to look them up by path? The problem is not so much looking them up, but reading them, as far as I understand, those bits are really central to KService, and quite entangled at that. I don't think you'll have much luck cutting that out there to make it usable on its own -- but then, maybe you find a way... Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: desktoptojson and list properties
On Monday 17 November 2014 18:35:51 Sebastian Kügler wrote: On Monday, November 17, 2014 02:04:51 Aleix Pol wrote: On Mon, Nov 17, 2014 at 12:24 AM, Milian Wolff m...@milianw.de wrote: snip Fine, I could add similar code to desktoptojson, but: Since desktoptojson will be called for the plugins we ship in KDevplatform, how would/could I make desktoptojson know about the kdevelopplugin.desktop file without it being installed yet? that would not work here as our service type is still unknown to kbuildsycoca! Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? That should be possible, you can just drop the json file in there, and reference that in the K_PLUGIN_FACTORY_WITH_JSON macro. So scripty and the ki18n crew can cope with .json files nowadays? No reason to use .desktop at all anymore? That would be an acceptable solution for me. Though I guess desktoptojson should get a big fat warning that this it is deprecated and one should better write .json directly to prevent such issues from occurring randomly in other projects. Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: desktoptojson and list properties
On Sunday 16 November 2014 23:52:25 Milian Wolff wrote: Hello all! KDevelop is currently bitten hard by a bug/limitation in desktoptojson. It does not actually understand the .desktop files and custom properties get converted to plain JSON strings. Looking at the sources it's also clear why, only a selected list of .desktop properties is interpreted as lists. We have a custom kdevelopplugin.desktop file that describes our custom properties via something like: [Desktop Entry] Type=ServiceType X-KDE-ServiceType=KDevelop/Plugin X-KDE-Derived=KPluginInfo Name=KDevelop Plugin ... [PropertyDef::X-KDevelop-Interfaces] Type=QStringList ... To me it looks like I'll have to add support for such files to desktoptojson. But I wonder: Where was/is the code for the above files (how are they called?)? Apparently these are KServiceType's and the code can be found in kservice. In kservice.cpp's KServicePrivate::property we see code like this: // No luck, let's ask KServiceTypeFactory what the type of this property // is supposed to be. // # this looks in all servicetypes, not just the ones this service // supports! KServiceTypeFactory::self()-findPropertyTypeByName(...) Fine, I could add similar code to desktoptojson, but: Since desktoptojson will be called for the plugins we ship in KDevplatform, how would/could I make desktoptojson know about the kdevelopplugin.desktop file without it being installed yet? that would not work here as our service type is still unknown to kbuildsycoca! Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? Bye -- Milian Wolff m...@milianw.de http://milianw.de
Re: desktoptojson and list properties
On Mon, Nov 17, 2014 at 12:24 AM, Milian Wolff m...@milianw.de wrote: On Sunday 16 November 2014 23:52:25 Milian Wolff wrote: Hello all! KDevelop is currently bitten hard by a bug/limitation in desktoptojson. It does not actually understand the .desktop files and custom properties get converted to plain JSON strings. Looking at the sources it's also clear why, only a selected list of .desktop properties is interpreted as lists. We have a custom kdevelopplugin.desktop file that describes our custom properties via something like: [Desktop Entry] Type=ServiceType X-KDE-ServiceType=KDevelop/Plugin X-KDE-Derived=KPluginInfo Name=KDevelop Plugin ... [PropertyDef::X-KDevelop-Interfaces] Type=QStringList ... To me it looks like I'll have to add support for such files to desktoptojson. But I wonder: Where was/is the code for the above files (how are they called?)? Apparently these are KServiceType's and the code can be found in kservice. In kservice.cpp's KServicePrivate::property we see code like this: // No luck, let's ask KServiceTypeFactory what the type of this property // is supposed to be. // # this looks in all servicetypes, not just the ones this service // supports! KServiceTypeFactory::self()-findPropertyTypeByName(...) Fine, I could add similar code to desktoptojson, but: Since desktoptojson will be called for the plugins we ship in KDevplatform, how would/could I make desktoptojson know about the kdevelopplugin.desktop file without it being installed yet? that would not work here as our service type is still unknown to kbuildsycoca! Or can we nowadays write the .json files directly, i.e. can scripty/ki18n cope with them nowadays? So, any chance we can use .json directly here? Hi, I guess a solution would be to be able to provide the servicetype file as an argument to desktoptojson? Also given how the plan is to move away from kbuildsycoca database for these files (no?) maybe it would make sense to have an alternative way to look them up by path? Aleix
