desktoptojson and list properties / i18n of JSON files

[Milian Wolff]

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
mail at milianw.de
http://milianw.de