Fix string translation in Stats

[planarvoid]

Fixes #8114

This fixes the issue with dates and other strings not being translated when the user changes the language within the App settings. This uses the injected ContextProvider instead of Context. The ContextProvider keeps a copy of the context which gets updated whenever the user selects a new language.

To test:

• Have system language in English
• Go to Me/App settings
• Change language to something with different Month names (Czech)
• Go to Stats
• Check that all the strings are translated to your new language (except the strings which are missing translations in your selected language)

Update release notes:

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[peril-wordpress-mobile]

You can test the changes on this Pull Request by downloading the APK here.

[malinajirka]

This PR #7413 PR from Amanda might be useful for the review. I don't remember the details but I think Locale.getDefault() was causing some issues. 🤷‍♂

[planarvoid]

@malinajirka I think we have to use the getSafeLocale just for strings, it's not necessary for Dates (as is this case). For the other changes I've followed the example of other parts of the app.

[develric]

Like this Singleton Provider approach 👍

[develric]

Really minor np: what about using expression body function here? Eventually keeping explicitly the return data type for readability. I'm in any case fine with as it is already (basically a matter of prefs).

[planarvoid]

sounds good 👍 anything that reduces the boilerplate code is a good change :-)

[develric]

Hi @planarvoid, I followed the testing steps with Android API level 21 and 28 (with and without this patch) and it worked as expected. Good job! 👍

I think we have to use the getSafeLocale just for strings, it's not necessary for Dates (as is this case). For the other changes I've followed the example of other parts of the app.

This is also my guess also based on this comment. I'm not fully sure to get all the possible implications of the modification in ResourceProvider class in places like this and in general outside of stats code. TBH it's just a gut feeling and did not encounter any issue while testing, but I wanted to mention in case you fill it can be wort to have another couple of eyes on that part.

I left an extremely minor np in the code comments if you want to consider but you can leave as it is if you prefer.

During testing with develop branch without this patch I found an issue when selecting RTL languages (for example Hebrew). Basically the order of quick actions buttons and of the bottom nav bar items are not updated in RTL order with API > 24 unless you restart the app. Don't know if it was intentional but this PR seems to fix also that. I will open a dedicated issue to track this but wanted to mention in case you prefer to look into it in this PR explicitly, let me know 😊.

[planarvoid]

I'm not fully sure to get all the possible implications of the modification in ResourceProvider class in places like this and in general outside of stats code.

I don't think there should be any problem with the ResourceProvider. What I've done is that I've replaced the injected Application context with the same context from the provider. The only difference is that it's now updated when we change the language.

Don't know if it was intentional but this PR seems to fix also that.

We use the ResourceProvider all over the place so I think it will fix more stuff than we think :-)

[develric]

Thanks for this @planarvoid ! LGTM! 👍