Pushed in https://cgit.kde.org/gcompris.git/commit/?id=e5fdcc7aa210d26f5154dd48fd6b1a26573a7cd1

In D17739#396953, @huftis wrote:

I have tested the scripts and found one bug in poToDataset.py. It also converts obsolete entries in the PO file into JSON entries.

But I have a question. Is it necessary to also output the empty (untranslated/fuzzy) entries? If not, you can fix the bug and simplify the JSON files at the same time by just using:

for entry in poFile.translated_entries():
    word = entry.msgctxt
    data[word] = entry.msgstr

I don’t know how StaticMessages.sh stuff works, so I’m not qualified to test that part. But I’ve tested the POT and JSON generator scripts, and they seem to work perfectly.

Only set the translated values in the json file

I have tested the scripts and found one bug in poToDataset.py. It also converts obsolete entries in the PO file into JSON entries.

Use msgctxt to store the key of json file.
Write a new json instead of starting from an actual one

In D17739#396941, @jjazeix wrote:

In D17739#396924, @huftis wrote:

Since the filename, e.g. alarmclock.ogg, is used as the key in the JSON file, I think it would be cleaner to use it as a ‘msgctxt’ in the PO file. That way, you don’t have to try to parse the comments to extract the keys when regenerating the JSON files. And it makes it possible to have more the one image with the same ‘msgid’ (homographs with different meaning, e.g. a verb and a noun). (I don’t think there’s currently any such strings, but there may be in the future.)

I though about it at first and was afraid that the translator kept the .ogg extension in the translation. If it's safe, it will be easier. There is orange as color and fruit I think but orange-color.ogg is used for the color

The poToDataset.py script only seems to work if 1) there already *is* a JSON file and 2) the file contains an entry for the strings in the PO file. So someone needs to manually add the JSON file and keep the entries updated to reflect the original English JSON file. Wouldn’t it be easier to just write the JSON files based on the PO file? They should contain all the information needed to generate JSON files.

In D17739#396924, @huftis wrote:

Since the filename, e.g. alarmclock.ogg, is used as the key in the JSON file, I think it would be cleaner to use it as a ‘msgctxt’ in the PO file. That way, you don’t have to try to parse the comments to extract the keys when regenerating the JSON files. And it makes it possible to have more the one image with the same ‘msgid’ (homographs with different meaning, e.g. a verb and a noun). (I don’t think there’s currently any such strings, but there may be in the future.)

Since the filename, e.g. alarmclock.ogg, is used as the key in the JSON file, I think it would be cleaner to use it as a ‘msgctxt’ in the PO file. That way, you don’t have to try to parse the comments to extract the keys when regenerating the JSON files. And it makes it possible to have more the one image with the same ‘msgid’ (homographs with different meaning, e.g. a verb and a noun). (I don’t think there’s currently any such strings, but there may be in the future.)

Use urllib for both encoding and decoding.
Remove translation if fuzzy or update it if updated.

In poToDataset.py, only translated strings should be included. Currently, if a translator translates ‘foo’ to ‘bar’, waits until the JSON file is regenerated, changes their mind and deletes or fuzzies the translation (“I don’t think ‘bar’ is the correct translation for ‘foo’ after all, but I’m not sure what is the correct translation yet”), the JSON file is stuck with ‘bar’ as the translation.

Replace "%20" with " " when recreating the json file

Replace " " with "%20" in urls

One final, minor change in the URLs is need to make them clickable.

missing \n

Remove duplicate comment of the image links. Update the image link to the good one when there are spaces (we'll look after to remove the spaces).
Fix the header.
Use words_by_section.html page instead of words.html

A few suggested changes in the POT header.

Also, since (AFAICS) the words are organized by section in the PO file (that’s good), perhaps you should link to

In StaticMessages.sh, the call to the Python script in import_po_files is commented out. Is this intentional?

The link in comment section in your example doesn’t work (and why are they duplicated, BTW?):

Pushing it in a few hours if no complains :). Note that there is a script to fill it for languages which already have translated it in the json files

railroad fixed in a0fb2028f924c370de8db104539c8e5ccfac7a42

hanoi fixed in 98d98eb160987f4d2f58973a13c7a1dddac821fb

bargame fixed in e6ba64d11c362c66b8d9044ee99cb94a09fb22ee

Generates po with lines looking like:
#. otherChapter / number / U0039.ogg
#. https://gcompris.net/incoming/lang/words.html#nine
#: https://gcompris.net/incoming/lang/words.html#nine
msgid "nine"
msgstr ""

money activities fixed in 326f6410153b82a55862328509800d36c47fcb06
was just a bad id issue

In D17739#391965, @huftis wrote:

The information seems sufficient. But could you split it over two lines instead, and add space after colon? I recommend:

#. Description: "alphabet"
#. Image: https://www.gcompris.net/incoming/lang/lang/words/alphabet.png

Yes, it is very useful to have it in the PO format instead of the JSON format.

Thanks, I'll take a look. Other similar script that can help understanding: https://cgit.kde.org/plasma-browser-integration.git/tree/StaticMessages.sh

I think you should be using StaticMessages.sh

Will be commited next week if no complains, scripts to convert from json to po and opposite done.

After implementing multipledataset in algebra_by, I have a clearer view about the icons to set the difficulty of each activity.
I would prefer if the multipledataset choice is done from the menu bottom rather than within the activity.

A few notes (pros/cons) on programming side:

• Using the in-menu choice:

We only need to update the menu code once, and for each activity, add the datasets, levels in ActivityInfo.qml and update the logic to use the dataset.

• Using the configuration in activity:

For each activity, we need to add the datasets, levels in ActivityInfo.qml and update the logic to use the dataset.
Plus, adding/updating the configuration dialog, finding a way to not have to duplicate it on all the activities, finding a common generic way to load/store the information. Once it's changed, we need to restart the activity to first level + handling correctly if there are other configuration changes.

After discussion with @echarruau on irc we agreed on a few points. We can make dataset settings a section of the Activity settings page we already have; we can probably put it even on top of other activity settings.
I will probably update the Activity setting button look to be more obvious (like a big wheel or something...).
It may not be really necessary to have access to activities settings from the main menu, it's enough for main users to do it from the in-activity button.

I did not think about this, as I only run multidataset branch on computer, but you are right! No way to have favorite + multidataset on my small phone :(

The problem with using the activity corner as a button is that it is really too small area for a button on small/phone screen. It is already a problem with the sun icon to set as favorite that is a little too small also in this case. I'd rather find a way to fix this than extend the issue...

For me the selection of Dataset should be accessible from the icon located top left of every activity with multidataset, like it is implemented at the moment in multidataset branch, this is very convenient!
The windows that opens should display all the multidataset levels corresponding to the nb of stars chosen.

Copy of the pad I started there: https://semestriel.framapad.org/p/multipledatasetgc

Committed in https://cgit.kde.org/gcompris.git/commit/?id=d7a7e4e0fc30581604755f2b05441a3af32f1b70
Thank you!

Oops, seems Johnny and I made comments at the same time :p

Really nice patch! Good work :)
Once the diff is updated according to comments, it'll be good I guess.

The new file that you created MoneyArea.qml isn't included in the diff. Can you do the following:
git add -A
git diff --staged > patch.diff

Commited in https://cgit.kde.org/gcompris.git/commit/?id=942d53e08f48b95491967e0db64fa5957f4475ef

GCCreationHandler is now integrated with all the configurable activities. Closing this task.

Commit link: https://cgit.kde.org/gcompris.git/commit/?id=7f56fc2d9c3a76419ef054fc4e440b18d08941e9

In D17151#365789, @jjazeix wrote:

Will existing created levels (via the old method) still available? If not, we need to be able to convert the old levels format to the new one and don't lose them

Will existing created levels (via the old method) still available? If not, we need to be able to convert the old levels format to the new one and don't lose them

used this site https://whatsmychaincert.com/?gcompris.net
showed the error and drived bcoudoin to a fix. It created a chain certificate and installed it in gcompris.net
changed apache's configuration to use it. In the SSLCertificateChainFile it now point to this file