[BUG]: The story/topic completion text does not update after the app language is changed.

[seanlip]

Describe the bug
After selecting a language and navigating back to the options menu, the sidenav still shows the stories/topic completion in the old language.

To Reproduce
Steps to reproduce the behavior:

1. Go to the Options menu, e.g. from the sidenav.
2. Click on "App Language".
3. Click on the Arabic option.
4. Return to the Options menu.
5. Click on the hamburger dropdown to open the sidenav. Notice that everything is in Arabic except for the "0 Stories Completed | 3 Topics in Progress" text.
6. Return to the homepage. The "0 Stories Completed | 3 Topics in Progress" text is fixed and now appears in Arabic.
7. Click back into Options > "App Language" and select English.
8. Return to the Options menu.
9. Click on the hamburger dropdown to open the sidenav. Notice that the "0 Stories Completed | 3 Topics in Progress" text now appears in Arabic, whereas everything else appears in English.

Expected behavior

• In Step 5, the "0 Stories Completed | 3 Topics in Progress" text should also be translated to Arabic.
• In Step 9, the "0 Stories Completed | 3 Topics in Progress" text should remain in English.

Demonstration

Environment

• Device/emulator being used: Moto device
• Android or SDK version (e.g. Android 5 or SDK 21): Android 8
• App version (you can get this through system app settings or via the admin controls menu in-app): 0.11-beta-8c81c98d8b

[BenHenning]

I think this also affects dialogs from what I've seen back when implementing the internationalization work. I think the issue splits into two different problem areas:

• Dialogs
• The navigation drawer (which I believe is not a dialog)

Dialogs have a separate context from the activity that they're hosted in, so I'm not quite sure how we ensure that they receive the correctly initialized context upon a recreation. Perhaps we need some custom work in an InjectableDialogFragment base class?

The navigation drawer one is a bit more confusing to me because it should just be using the same context as the host activity (which would be recreated upon a language change) when selecting language. Resource selection is quite complicated in Android, however, so it's possible a different resources object is being used for these strings in particular (maybe the application context's resources?).

[aryanmishra29]

Hi @adhiamboperes, I am unable to reproduce this BUG because the App Language Option Leads to an empty activity.
Video Description
Oppia_AppLangBUG.webm

[adhiamboperes]

Hi @adhiamboperes, I am unable to reproduce this BUG because the App Language Option Leads to an empty activity. Video Description Oppia_AppLangBUG.webm

This is due to #5106. If you're unable to run bazel, could you try to repro a different issue?

[aryanmishra29]

Sure @adhiamboperes.

[adhiamboperes]

@whyash8, could you PTAL at this issue?

[whyash8]

Ok I will take a look.

[whyash8]

please assign me this issue

[adhiamboperes]

ERROR: /home/yash-sharma/.cache/bazel/_bazel_yash-sharma/be3345fe8849b7df3b0505581d7f3bab/external/maven/BUILD:3492:11: AarResourcesExtractor external/maven/_aar/unzipped/resources/com_google_android_material_material failed: (Exit 127): aar_resources_extractor failed: error executing command bazel-out/host/bin/external/bazel_tools/tools/android/aar_resources_extractor --input_aar ... (remaining 9 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox aar_resources_extractor failed: error executing command bazel-out/host/bin/external/bazel_tools/tools/android/aar_resources_extractor --input_aar ... (remaining 9 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox /usr/bin/env: 'python': No such file or directory /*getting this error while building bazel for this application version 0.11-beta-8c81c98d8b// please help to solve @adhiamboperes

@whyash8, please move this to discussions as it is not related to this issue.

[whyash8]

Hi @adhiamboperes,

Can you please provide guidance or suggestions on how to start solving this issue? Specifically, any pointers on which files or parts of the codebase I should focus on would be greatly appreciated. I have already setup the appVersion needed for this issue .

Thank you!

[adhiamboperes]

@whyash8, NavigationDrawerHeaderViewModel is the class responsible for populating this text. profileTopicProgressText and profileStoryProgressText are the affected variables. Some possible causes for the language not updating for the specified strings when language changes are:

• Wrong initialization order: profileTopicProgressText and profileStoryProgressText depend on ongoingTopicCount and completedStoryCount, which are initialized after the ObservableFields. This may cause incorrect initial values for the ObservableFields.
• Lifecycle timing and binding-related synchronization issues between the ViewModel and the UI.
• The headerBinding is bound to the headerViewModel, but executePendingBindings is not explicitly called for headerBinding. If the binding doesn't receive updates immediately, the ObservableFields in the headerViewModel might update, but the UI won't reflect these changes until the next layout pass.
• Adding the header view (addHeaderView) is done before the LiveData has fully emitted its results. If the LiveData observers fire late, the header view won't automatically refresh.

These are options you can eliminate and can guide you to understand why the update is failing.

[whyash8]

Hi @adhiamboperes ,

I am currently working on issue #5024 and noticed a difference between the release-0.11 and develop branches in the NavigationDrawerHeaderViewModel.kt file. Specifically, the release-0.11 branch has a single variable profileProgressText, while the develop branch has separated this into two variables: profileTopicProgressText and profileStoryProgressText.

I believe that aligning the release-0.11 implementation with the develop branch by introducing these two separate variables could potentially resolve the issue and improve the clarity and accuracy of the progress texts.

Before proceeding, I wanted to get your input on whether this would be the best approach or if there are any other considerations I should be aware of.

Thanks for your guidance!

[adhiamboperes]

@whyash8, could you please confirm that you are suggesting reverting to a single variable? Was this bug not present in 0.11?

[whyash8]

@adhiamboperes
The bug is not present in the develop branch and it exists in app version : 8c81c98 and i am suggesting to align the implementation of navigationdrawerheaderviewmodel of app version 8c81c98 with develop branch to resolve the issue in app version 8c81c98.

[adhiamboperes]

@whyash8, if the bug is not present in the current version of develop, but it was present in an earlier version, it means that it was fixed.

In such situations, we prefer to identify the commit that fixed the issue, and then we can verify that the bug was present before, but not after that commit. In order to do this, we use git bisect. Since you have identified a “bad” commit(8c81c98) where the bug existed, and taking the latest commit on develop as good commit, you can use git bisect until you find the first “good” commit where the bug was fixed.

Once you are able to locate it, we should be able to close this issue.

Here’s a link to git bisect documentation: https://git-scm.com/docs/git-bisect

[swarnalicoder]

Hi @whyash8,
I’m a beginner in Android development and would love to help with resolving this issue. I’ve been learning about navigation drawers and language handling in Android, and I’m excited to contribute. Can you guide me on which files or sections of the code I should focus on?

[whyash8]

@swarnalicoder please look at a different issue . This is already assigned

[whyash8]

Hi @adhiamboperes ,

After performing several iterations of git bisect as advised, I have identified that commit 3a369ed (Fixes part of #4120, part of #1051: Fix a lot of build-time warnings (#5402)) resolves the issue #5024.

Thank you for the guidance.

Best regards,
@whyash8

[whyash8]

Commit 3c7713d

[whyash8]

Commit 3a369ed which resolved the issue.
PTAL @adhiamboperes