Learn > Continue learning shortcut tiles mixing up languages in Khan lessons

[rtibbles]

Observed behavior

The “Home” “Continue learning on your own” shortcuts are showing the same exercises from Khan Academy, but not in the language the learners are working in. Our Kolibri systems host two, if not 3 different language versions of Khan Academy. In our case, learners are working in the Fulfulde version of Khan early math. The tiles to continue learning are showing first a shortcut to a French-language version of a lesson. I then tested it with another lesson in Fulfulde and the shortcut tile came up pointing to an English version of the same lesson. I’ll include a screenshot below.

This creates confusion for our learners, many of whom are very new to all of this.

Steps to reproduce

Import equivalent resources from Khan Academy in two different channels.
Engage with the resource in one language.
Look at resume.
See that it sometimes shows the resource in the wrong language.

Errors and logs

The following screenshot shows 2 shortcut tiles pointing to English-version lessons, but they are in reference to the same lessons that were being worked on in Fulfulde.

Forum report: https://community.learningequality.org/t/learn-continue-learning-shortcut-tiles-mixing-up-languages-in-khan-lessons/2965

Expected behavior

This issue is specific to Khan Academy, because of the decision to have the same content_ids for resources that represent translations of Khan Academy resources, when in different languages.

This was probably a mistake, but not something we can cleanly resolve because of historic data.

To ameliorate this we should prioritize the resource in the user's current language when we deduplicate by content_id in the frontend - that would still have the issue of showing '10 locations' in the instance shown in the screenshot, but the primarily linked resource displayed in the card could be prioritized to the language the user is engaging with the platform in.

It is possible that we could also use content session log information (which from 0.15 onwards contains additional node_id records) to refine this further, but this could have significant impacts on performance of the resumable nodes query - worth experimenting with, however!

User-facing consequences

…

Steps to reproduce

…

Context

Version: 0.15.12
OS: Linux-6.1.21-v8±aarch64-with-glibc2.31
Python: 3.9.2
Installer: deb kolibri-server - 0.4.0-0ubuntu2
Server: nginx/1.18.0
Database: /home/pi/.kolibri/db.sqlite3
Free disk space: 626 GB
Server time: Fri Jan 19 2024 20:03:53 GMT+0100 (West Africa Standard Time)
Server timezone: Africa/Douala
Device ID: 86a460380dbbc8ff95b31688d3694024

Devices: iOS, Android, MacOS
Browser: Safari, Chrome

[FidalMathew]

@rtibbles @marcellamaki can I work on this?

[rtibbles]

Yes, please follow the first approach outlined:

prioritize the resource in the user's current language when we deduplicate by content_id in the frontend

Target the 0.16 release branch, but note that we will not merge any PR until 0.16.0 has been released.

[FidalMathew]

Hi @rtibbles I have reproduced the issue. Could you guide me a bit more on how to approach this? How can we prioritize it?

[rtibbles]

Ah, apparently the intended behaviour was already attempted to be implemented, here: https://github.com/learningequality/kolibri/blob/release-v0.16.x/kolibri/plugins/learn/assets/src/utils/contentNode.js#L13

It seems that the implementer (me) has done something wrong or something that doesn't quite work here. Either the language codes are not matching as intended, or I have used the sortBy function incorrectly! https://lodash.com/docs/#sortBy

[FidalMathew]

Hi @rtibbles the sortBy function is sorting based on the language of the platform language, i.e. English in my case. We want the result to be by the language of the resource the user views the content in. We want to prioritize the feed based on the recently viewed resource, am I correct?

I'm thinking of using the contentNodeProgressMap which currently stores the content_id and its progress to store the language of the resource as well. This would solve the issue and the user will view the resource which they worked on recently. Let me know what you think.

[rtibbles]

The issue still is that the contentNodeProgressMap and any content progress stored in the database is keyed by the content_id, which in the case of the Khan Academy resources is shared across different languages for the translations of the resource.

The intention of the fix I was proposing was to present the resource that best matched the user's currently expressed language preference, as indicated by their choice of interface language.

Did you verify that if you change the interface language, it does properly prioritize another resource?

[FidalMathew]

@rtibbles Thank you! I understand the approach to tackle the issue and currently, changing the interface language does not properly prioritize the required same language resource.

Just asking a general question, regarding my previous approach. Like we have progress shared across different languages for the translations of the resource. I was thinking of having a variable such as viewLanguage to set the latest viewing language across all translations of the resource. Isn't this plausible?

[rtibbles]

This would work when navigating around in learn, but as soon as the user navigated somewhere else, or opened a new browser session, we would lose this information.

The more involved approach I outlined above is similar to this, in that we do store the distinct id of the resource (which is language specific) in the database (from 0.15.0 onwards), so we do in theory have this information. The only issue would be that using this information, which is stored in a JSON blob, directly in our query for 'resumable resources' would involve what is probably a much less performance database query than what we are currently using - hence the workaround I suggested.

The middle ground might be to return this information when available with the progress data, but also this is only stored on the ContentSessionLog model, whereas the returned progress we use in the frontend comes from the ContentSummaryLog model.

So, in short - yes, some different, more involved approaches would solve this slightly better, I just don't know if they're worth the energy, given that this only really affects Khan Academy resources specifically.

[FidalMathew]

Thank you @rtibbles for the explanation! 😀

[FidalMathew]

@rtibbles Thank you! I understand the approach to tackle the issue and currently, changing the interface language does not properly prioritize the required same language resource.

@rtibbles Sorry, I mistook a video for the above trial example. When I checked again, I didn't find any error in the sorting function, and it is working as expected. I switched between Spanish and English and sorting resources is working properly i.e. I'm viewing the resources in my preferred language if present in the continue learning section.

[rtibbles]

Interesting - I think I had better follow up with the forum poster to see whether using the interface language would be helpful then!

[FidalMathew]

@rtibbles I think since the forum poster has been using the English version of Kolibri, therefore the continue learning section points to the English version of the resource if present.

https://community.learningequality.org/t/learn-continue-learning-shortcut-tiles-mixing-up-languages-in-khan-lessons/2965/2

[rtibbles]

From the follow up, it appears that learners are indeed using the platform in Fufulde. I suspect the issue here is that there is a mismatch between the content language and the platform language. My suspicion is that the language code for the content is a three letter language code, while our platform language is a two letter code.

The Kolibri QA channel should include Khan Academy content in Fufulde - if you could see if you can replicate this issue specifically in Fufulde, with the interface in Fufulde, that would be helpful. We can then inspect the language codes that are being compared to understand where the issue is happening.

[rtibbles]

Hi @FidalMathew - thanks for your investigation here, I am going to pick this issue up, as I believe I know what is causing the issue and the best way to solve it.

[marcellamaki]

Closed with #12152