* origin/develop: (294 commits)
Fix incorrect fallback when English is set to first language
Fix eratic test for POST /api/pleroma/admin/reports/:id/notes
After code review
Support fallbacking to other languages
Delete report notifs when demoting from superuser
Update Caddyfile to Caddy v2
Lint
Support multiple locales from userLanguage cookie
Support multiple locales formally
Make lint happy
Add test for fallbacking to a general language
Fallback to a variant if the language in general is not supported
Add changelog
Document API addition
Allow user to register with custom language
Allow update_credentials to update User.language
Send emails i18n'd using backend-stored user language
Make all emails translatable
Fix digest test
Make mail and mailer translatable
...
It retrieved two ReportNotes and then checked one of them. But the order isn't guaranteed, while the test tested on the content of the first ReportNote.
I made the test on the content more generic
When someone isn't a superuser any more, they shouldn't see the reporsts any more either.
Here we delete the report notifications from a user when that user gets updated from being a superuser to a non-superuser.
elixir gettext current does not fully support fallback to another language [0].
But it might in the future. We adapt it so that all languages in Accept-Language
headers are received by Pleroma.Web.Gettext. User.languages is now a comma-separated
list.
[0]: https://github.com/elixir-gettext/gettext/issues/303
For an example, here, zh is not supported, but zh_Hans and zh_Hant
are. If the user asks for zh, we should choose a variant for them
instead of fallbacking to default.
Some browsers (e.g. Firefox) does not allow users to customize
their language codes. For example, there is no zh-Hans, but only
zh, zh-CN, zh-TW, zh-HK, etc. This provides a workaround for
those users suffering from bad design decisions.
For some reason I had a test who suddenly failed, mix test test/pleroma/web/o_auth/app_test.exs:54. A user has a list of applications and this test adds them and then sees if the list it gets back is the same as the apps it added.
When I ran mix test a day before I didn't have this problem and when I pushed code today in a different MR, the pipeline succeeded (see https://git.pleroma.social/ilja/pleroma/-/jobs/205827), yet locally it failed. So it seems the test can sometimes succeed and sometimes fail, which makes it untrustworthy.
The failure I see is because the returned list is in reverse order. I assume that's not per sé wrong. You just want to know if the apps you added are actually there. I fixed the test by first ordering the lists before comparing.
AFAICT (and as far as that's relevant) the test got introduced in commit cb2a072e62
