Fix root global page active locales

[janbrasna]

One-line summary

Shows only applicable languages for navigating to the home page on global / root.

Significant changes and points to review

1. The current / locale choice root lists active_locales based either on its own view (404 in fact) language files, or more likely because the metadata checks coincidentally use the first locale file in the folder and the 404.ftl comes first. But the proper active_locales for homepage have to be read from mozorg/home.ftl instead.
2. Even with locales populated based on the correct page, there still might be some that are not enabled in settings, so a check to only offer locales that can be navigated to is added.

Issue / Bugzilla link

Fixes #15010

Testing

(in prod mode, with Dev=False for restricted languages & Debug=False as the root is 404)
http://localhost:8000/ (with Accept-Locale empty)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.68%. Comparing base (d32bb17) to head (bc2d790).
Report is 35 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #15025      +/-   ##
==========================================
+ Coverage   77.64%   77.68%   +0.04%     
==========================================
  Files         162      162              
  Lines        8341     8359      +18     
==========================================
+ Hits         6476     6494      +18     
  Misses       1865     1865              

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

[janbrasna]

So, umm, instead of butchering the getter above it (potentially affecting gazillion page hits), it felt safer to just add a new one, doing just this one job checking for homepage languages separately, and using that in addition for the is_root condition. Maybe stupid, take this as more of a pseudo-code @stevejalim, and tear it apart as you see fit.

The hardcoded path string feels somewhat fragile here. Is there a better way?
(Also, some clever tests to cover the root specifics?)

[robhudson]

The path seems fine as long as we have a test that leverages this. That way if it gets refactored away at some later point in time a test will break to know we depended on that.

[janbrasna]

I was thinking whether having an entry in SETTINGS would be more resilient, to keep the value of "homepage" locale file managed and visible in an obvious place, instead of having a string hardcoded somewhere deep in the code.

[janbrasna]

I'm still not entirely sure the separate method is needed, as from I can infer it looks like the

bedrock/lib/l10n_utils/fluent.py

Lines 83 to 85 in bc2d790

	def active_locales(self):
	# first resource is the one to check for activation
	return get_active_locales(self.resource_ids[0])

right above the addition only does that, can't seem to find any use besides listing active locales (presumably for home page), but using the first ftl file which is the 404 file — and can't think of use case that would benefit from reading the activation threshold for a locale based on that 404 file per se… so I'm doubting whether a separate method is not overly safe, and the original method shouldn't be updated to look for the metadata in a homepage ftl file, instead of the 404 resource_id. (But wasn't able to inspect all the layers this gets used throughout the app, so can't tell there's not a specific use case that I wasn't able to find…)

[janbrasna]

I had to pick a place where to allow only approved locales among all the layers it travels through… but it seemed the least intrusive to just do it here, after getting stuff from either context or l10n instance, and also before adding any extra locales in case the extras are intentionally outside of the allowed range, not filtering them out later. Also, not filtering if the language list comes from other source as CMS translations or activation files (=keeping most of the current logic intact and only making changes that may ever impact the is_root case).

[robhudson]

This seems good, we'd just want to add some tests around the changes before merging.

[janbrasna]

@robhudson Absolutely! That's actually why I cried for help, as I don't really have the imagination necessary to architect good tests around this, sadly. Some quirks that come to mind when thinking about where to even start:

• the page comes from an error handler output iiuc…
• the activation metadata is pulled from a separate repo and I don't even know how to stub it in code, just that there are some management commands around it…
• this is being handled on l10n_utils.render that's probably patching something somewhere…?
  etc., there's a lot insider knowledge needed for that I'm afraid;)

[janbrasna]

Originally posted by @janbrasna in #15010 (comment):

This is getting a bit complicated now with three home ftls:

1. mozorg/home-m24.ftl
2. mozorg/home-new.ftl
3. mozorg/home.ftl

with varying activation metadata.

Normally a "good enough" check might be for the activation of the oldest home.ftl file for home-old (?xv=legacy) that is the "lowest common denominator" fallback if nothing better exists, however this is not 100% correct:

A corner case might be e.g. a locale that never had home-old or home-new translated, but got active recently and completed home-m24 localization — such language should also be listed in the global root as active.

So a correct way might be to set union of all three for good measure?

Or, basically, look at how e.g. the language picker does it for home (paths), to offer all the locales, no matter if they are available for m24, new or old, in one list.