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