Implement a channel language filter.

[rtibbles]

Summary

• Adds a filter for channel languages on the main Library page and each remote library browsing page
• Populates the filter options only from the language property of the channel/root node metadata as the included_languages metadata currently only includes the language id and not the name.
• When a language has not been specified (i.e. on first page load), the user is redirected to the language that is the closest match to their interface language. If none exists, no language is selected.
• Displayed channels are displayed based on an exact match between the selected language and either their channel language, or their included languages property

References

Fixes #12702

Reviewer guidance

Open questions:

• What, if any, effect should the channel language selection have on the 'language' selection for resource/folder search?
• The language match can be very exact - for example in the first screenshot above where we only see two resources because that's what is in Castillian Spanish specificaly - because we mostly use language + region codes for our interface language, but our content languages are a mix of language and region codes, and just language codes. An alternative would be to do a less strict filtering, so we include all channels that are at least a language only match, so for example, if es-es is the selected language we would show:
  • First all the es-es channels
  • Then all the es channels
  • Then all the es-* channels

After updates:
Main open question is around how we are doing the filtering - currently, we use the fact that we are already fetching all the language metadata in the frontend to then send all relevant language codes to the backend in the API request.

This is a neat solution, but does mean we are adding an explicit chain step to our request waterfall - i.e. we have to wait until we've fetched the global search labels before we can fetch anything else.

The other alternative we could do there would be to instead just leverage the fact that we only really care about matching on the lang_code attribute - the part before the dash. We could add a new filter query to the API endpoint and then do matching on the backend against that.

In either case, we could potentially also still improve query performance here by making a language bitmask for the most frequently occurring languages, and annotate for quicker lookups - falling back to matching against the M2M included_languages when requesting languages not included in the bitmask.

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.18.0a0.dev0_git.197.gadb5455d.pex
Windows Installer (EXE)	kolibri-0.18.0a0.dev0+git.197.gadb5455d-windows-setup-unsigned.exe
Debian Package	kolibri_0.18.0a0.dev0+git.197.gadb5455d-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.18.0a0.dev0+git.197.gadb5455d.dmg
Android Package (APK)	kolibri-0.18.0a0.dev0+git.197.gadb5455d-0.1.4-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.18.0a0.dev0+git.197.gadb5455d.zip
TAR file	kolibri-0.18.0a0.dev0+git.197.gadb5455d.tar.gz
WHL file	kolibri-0.18.0a0.dev0+git.197.gadb5455d-py2.py3-none-any.whl