Describe the bug
The application fails to set its own Local correctly. This becomes visible when the System Locale and the Application Locale differ. This can lead to the UI being in German while the App language is set to English. This bug most likely caused #1589, #1585 and maybe #1517.
To Reproduce
Steps to reproduce the behavior:
Set System Locale/language to english and Application Locale/language to german or vice versa
Open any of the Activities under the About section of the NavigationDrawer.
Press the back button
Open any of the Fragments under except the Activites under the About section
All Fragments except the Activites under the About section are now in the System language while the NavigationDrawer and the Activies under the About are still in the Application language.
Expected behavior
Everyhting should be in the Application language.
Smartphone (please complete the following information):
Phone: Pixel 6
OS version: 13
Language: System German, Application English (same the other way around)
Suspected cause
The Application Locale is currently set in the BaseActivity under initLanguage. This works fine as long as only Fragments are openend and no Activity. The problem with the approach of setting the Locale as it is currently done is that is is only set for one Context. I suspect that when calling an Activity the Context changes thus reseting the Locale. This could in theory be counterd by setting the Locale again for the new Context. But in practice this was not succesfull. I believe the reason for this is that the Fragments are partly created by using injection and the injection is controlled by a Factory which Context seems to be generated outside of the normal ApplicationContext thus using the System Locale. For me it was not possible to access this Context and set the Locale manually. I have described what I believe to be the best and most straightforward fix below.
Fix for the issue
In SDK 33 Android introduced an LocaleManager or the option to set android:localeConfig see here. I believe this could fix the problem as the Locale is set Application wide and not only for one context. Unfortunalty the Application is currently using SDK 32 as its build SDK as well as SDK 26 as min SDK. While I do think that the min SDK of 26 should not be a problem we would definitely have to bump the build SDK.
Describe the bug The application fails to set its own Local correctly. This becomes visible when the System Locale and the Application Locale differ. This can lead to the UI being in German while the App language is set to English. This bug most likely caused #1589, #1585 and maybe #1517.
To Reproduce Steps to reproduce the behavior:
Expected behavior Everyhting should be in the Application language.
Smartphone (please complete the following information):
Suspected cause The Application Locale is currently set in the BaseActivity under initLanguage. This works fine as long as only Fragments are openend and no Activity. The problem with the approach of setting the Locale as it is currently done is that is is only set for one Context. I suspect that when calling an Activity the Context changes thus reseting the Locale. This could in theory be counterd by setting the Locale again for the new Context. But in practice this was not succesfull. I believe the reason for this is that the Fragments are partly created by using injection and the injection is controlled by a Factory which Context seems to be generated outside of the normal ApplicationContext thus using the System Locale. For me it was not possible to access this Context and set the Locale manually. I have described what I believe to be the best and most straightforward fix below.
Fix for the issue In SDK 33 Android introduced an LocaleManager or the option to set android:localeConfig see here. I believe this could fix the problem as the Locale is set Application wide and not only for one context. Unfortunalty the Application is currently using SDK 32 as its build SDK as well as SDK 26 as min SDK. While I do think that the min SDK of 26 should not be a problem we would definitely have to bump the build SDK.