desktoptojson and list properties / i18n of JSON files

Burkhard Lück lueck at hube-lueck.de
Fri Nov 21 15:34:16 GMT 2014


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





More information about the kde-core-devel mailing list