desktoptojson and list properties / i18n of JSON files

[Milian Wolff]

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. 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? 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?

Thanks!
-- 
Milian Wolff
mail at milianw.de
http://milianw.de