Food preferences language does not change immediately after app language change

[teolemon]

What

• Food preferences language does not change immediately after app language change
• Spotted as we were demoing the app to a European Commission employee

[monsieurtanuki]

Food preferences language does not change immediately after app language change

@teolemon If you mean the following data, that's because we use the server for localized data:

[{
  "id": "not_important",
  "name": "Not important"
}, {
  "id": "important",
  "name": "Important",
  "factor": 1
}, {
  "id": "very_important",
  "name": "Very important",
  "factor": 2
}, {
  "id": "mandatory",
  "name": "Mandatory",
  "factor": 4,
  "minimum_match": 20
}]

Given the very small number of labels to localize in init_preferences_en.json (4) we could do that as "normal" .arb translations, instead of using the server for that, what do you think?

PS: the same solution may not apply regarding init_attributes_groups_en.json because there are much more items to localize (or we limit to a couple of local localizations per attribute as a fallback while downloading).

[{
  "attributes": [{
    "icon_url": "https://static.openfoodfacts.org/images/attributes/dist/nutriscore-a.svg",
    "setting_note": "The Nutri-Score is computed and can be taken into account for all products, even if is not displayed on the packaging.",
    "name": "Nutri-Score",
    "default": "very_important",
    "setting_name": "Good nutritional quality (Nutri-Score)",
    "id": "nutriscore"
  }, {

...

[abdullah-khudher]

@teolemon I didn't face this bug when I tried to change the language (in debug mode).

What i did: 1- Open the app. 2- Go to App settings screen. 3- Change language.

Please see the video: https://www.youtube.com/shorts/8Rj9cmulnq0

[monsieurtanuki]

@abdullah-khudher The call to refresh is instant anyway. But how fast will the download be? And haven't we cached the downloaded file in a previous language change?

[monsieurtanuki]

@teolemon There's no way we can solve this issue as is:

• we cannot guarantee that the connection and the server would be ok at any moment, more specifically when you change the language
• I would be ugly to store all localizations in the app assets "just in case"

That said, if you want to have a better "demo" effect, we can imagine something specific (like pre-downloading specific language localizations in dev mode).

But there's something not working here; it looks like you have to close the app so that in the next restart the localizations will be downloaded (if needed) and displayed. @LuanRoger Do you feel like solving this issue?

[LuanRoger]

Sure! I'll investigate this later, but what I've figure out for now:

that's because we use the server for localized data.

That's made by the ProductPreferences, but he's just called once since the app started (more specifically on app_navigator), so probably, this is the only moment that the localization is pulled from the server, when the app starts.

Some possible solutions I can think for now:

• Use the .arb files (as mentioned by @monsieurtanuki) as a "local" and network/server independent solution.
• Refresh the food preferences in some other moment on the app (when the user enter on the food preferences page, idk yet). This come with a pitfall:
  • Could cause UI frozen during the download, so it would be good run it on a background tasks or just show a simple progress bar when enter on the preferences pages during the download.
• A more sophisticated one, could create a sort of language history to cache the ones that the user already pulled from the server, so when he changes the language again, it will check the cache and if exist the it will use it. But this would be a more complicated solution than just use the .arb files, since the localization will be local anyway.

[monsieurtanuki]

@LuanRoger Let me give you some additional info:

• we store one localization in the assets (English) as a fallback. As the app supports dozens of languages and there are about 30 items to localize, including verbose warnings regarding allergens, storing all the localizations in assets (or .arb) would probably not be a relevant option, let alone the induced lack of flexibility
• when we download a localization, we already store it locally so next time it's needed we don't use the server
• the problem here is that when we change the language we don't even check if we have a localization or try to download it - that is the issue. As I coded it a long time ago I'm almost certain that it worked, but since then many things changed, and our new route management or fixes about the classes in main.dart being refreshed too often may explain why we don't try to use the correct localization.
• we probably don't really need background tasks here, but just an async without an await. It's also called at app start anyway.

TL;DR It used to work, the main thing here is to call the specific localization refresh method when we change languages as an async without await.