feat: Tagline V3: support for countries-only locales: (eg _FR)

[g123k]

Hi everyone!

Today, we only support languages and languages+countries codes.
This PR allows supporting countries-only codes (e.g.: _FR)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.

Project coverage is 7.26%. Comparing base (4d9c7fc) to head (1ca2630).
Report is 200 commits behind head on develop.

Files	Patch %	Lines
...h_app/lib/data_models/news_feed/newsfeed_json.dart	0.00%	10 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           develop   #5370      +/-   ##
==========================================
- Coverage     9.54%   7.26%   -2.29%     
==========================================
  Files          325     391      +66     
  Lines        16411   20038    +3627     
==========================================
- Hits          1567    1456     -111     
- Misses       14844   18582    +3738     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[monsieurtanuki]

Today, we only support languages and languages+countries codes. This PR allows supporting countries-only codes (e.g.: _FR)

Just curious: is that supposed to happen one day? Doesn't seem to be the case in ios or android for the moment.

[g123k]

Today, we only support languages and languages+countries codes. This PR allows supporting countries-only codes (e.g.: _FR)

Just curious: is that supposed to happen one day? Doesn't seem to be the case in ios or android for the moment.

Both JSON are outdated (and they are also invalid).
For now, the idea is to deploy Nutri-score outside of France (that's one of the reasons 4.15.0 is still not released).
(And we still don't know when it will be…)

[monsieurtanuki]

What is supposed to happen with _BE: which language would be used?
Even if the text is supposed to be different for fr_FR and fr_BE, it will definitely be different for fr_BE and nl_BE.
Would make sense to use the language_country syntax, with language only and/or country only as a fallback.

[g123k]

What is supposed to happen with _BE: which language would be used? Even if the text is supposed to be different for fr_FR and fr_BE, it will definitely be different for fr_BE and nl_BE. Would make sense to use the language_country syntax, with language only and/or country only as a fallback.

That's exactly what it is.

The order of priority is:

• Strict matching (so test if fr_FR exists)
• If not, we check if there is something with the language (fr)
• And then, by the country _FR (the feature of this PR)
• And if nothing is available -> default value

[monsieurtanuki]

And then, by the country _FR (the feature of this PR)

That's precisely what I don't get: in which cases are we supposed to receive messages with country but no language?
Have you been confronted to that? Are they supposed to send that?

Maybe it's similar to @yarons in #5339: using the app in Israel but in English, not in Hebrew, right?
Then we would be better off listing all the keys and finding the first one that matches .._IL, possibly with a preference for English in general.
Even then, we'll have either RTL or LTR languages, and that would need to be dealt with.

Anyway, I'm surprised we may rely on receiving _cc messages.
What do you think of my .._cc look-up suggestion: would that solve the "unexpected language x country combo" case?

[g123k]

And then, by the country _FR (the feature of this PR)

That's precisely what I don't get: in which cases are we supposed to receive messages with country but no language? Have you been confronted to that? Are they supposed to send that?

Maybe it's similar to @yarons in #5339: using the app in Israel but in English, not in Hebrew, right? Then we would be better off listing all the keys and finding the first one that matches .._IL, possibly with a preference for English in general. Even then, we'll have either RTL or LTR languages, and that would need to be dealt with.

Anyway, I'm surprised we may rely on receiving _cc messages. What do you think of my .._cc look-up suggestion: would that solve the "unexpected language x country combo" case?

The way the JSON is split is that we have on one side translated news and on the other a feed of news.
That's why we can ask for a feed for each country for example, with still translated content.

[teolemon]

👍

[teolemon]

Small merge conflict @g123k