Initial meilisearch implementation, doesn't delete posts yet

Instruct users to run 'git pull' as the pleroma user

StealEmojiPolicy: fix String rejected_shortcodes

* rejected_shortcodes is defined as a list of strings in the
  configuration description. As such, database-based configuration was
  led to handle those settings as strings, and not as the actually
  expected type, Regex.
* This caused each message passing through this MRF, if a rejected
  shortcode was set and the emoji did not exist already on the instance,
  to fail federating, as an exception was raised, swiftly caught and
  mostly silenced.
* This commit fixes the issue by introducing new behavior: strings are
  now handled as perfect matches for an emoji shortcode (meaning that if
  the emoji-to-be-pulled's shortcode is in the blacklist, it will be
  rejected), while still supporting Regex types as before.

Also use actor_type to determine if an account is a bot in antiFollowbotPolicy

Skip cache when /objects or /activities is authenticated

Ref: fix-local-public

Allow to skip cache in Cache plug

Ref: fix-local-public

Fix incorrect fallback when English is set to first language

Fix eratic test for POST /api/pleroma/admin/reports/:id/notes

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

Support fallbacking to other languages

Lint

Support multiple locales from userLanguage cookie

Support multiple locales formally

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

Make lint happy

Add test for fallbacking to a general language

Fallback to a variant if the language in general is not supported

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.

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

Make static fe translatable

Fix tests

Make mfa pages translatable

Make oauth pages translatable

Use proper lang attributes in htmls

Make tag feed translatable

Make password reset pages translatable

Make lint happy

Extract translatable text

Make remote follow pages translatable

Prefer userLanguage cookie over Accept-Language header in detecting locale

https://git.pleroma.social/pleroma/pleroma-meta/-/issues/60

After code review

Use patern matching to see if someone was superuser before

Delete report notifs when demoting from superuser

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.

mix: Check .git presence

Fix test get_user_apps/1

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 cb2a072e6252b7c3f6473f7cfd1af5c0ec732d7b

Add unicode 14 support
and add a test with a unicode 14 emoji

Add visibility check in context path (#26)

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/26

Merge pull request 'Purge gopher frontend' (#24) from purge-gopher into develop

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/24

Purge gopher frontend

Purge SSH frontend (#23)

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/23

Merge pull request 'Allow for embedding object data in publish' (#16) from undo-emoji-remote into develop

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/16

Remove debug prints

Allow for embedding object data in publish

Merge pull request 'emoji reaction standardisation' (#14) from emoji-reaction-standardisation into develop

Reviewed-on: https://akkoma.dev/AkkomaGang/akkoma/pulls/14

update api spec for custom emoji reaction

Bugfix: standardise scheme for emoji reactions

mix format

update changelog

ensure local statuses are not visible remotely

check for local_public? on AP route

cherry-pick security from upstream

Merge branch 'develop' of akkoma.dev:AkkomaGang/akkoma into develop

update changelog

Merge pull request 'Use mediaproxy for emoji notifications if enabled' (#7) from sn0w/akkoma:patch/emoji-notification-mediaproxy into develop

Reviewed-on: http://akkoma.dev/AkkomaGang/akkoma/pulls/7

Use mediaproxy for emoji notifications if enabled

format everything

update pleroma-fe url

update adminfe

Revert "update adminfe"

This reverts commit 4532f75da35b44386df9a3b1b193f8bb8120488a.

update adminfe

mix format

allow %{source} dict in no_empty

update fe

update pleroma-fe

bump version

update pleromaFE

Merge branch 'mfm' into develop

mix format

ensure tests pass

Allow authoring MFM

Merge pull request 'Allow reacting with emojis containing a number' (#6) from sn0w/akkoma:patch/broaden-emoji-name-scope into develop

Reviewed-on: http://akkoma.dev/AkkomaGang/akkoma/pulls/6

allow `source` from misskey

Allow reacting with emojis containing a number

bump version, 2.5.1

update pleroma-fe

Add emoji_url to notifications to allow rendering

Ref #5

fix event triggers

don't test

pls

update musl

try making it dependent

include musl tag

clean for musl

fix tag builds

ensure releases don't collide

bump version

run on tag

make sure we have zip

hex

ensure secrets get passed

just run release instantly for now

only test release

test on push

release on tag

update pleroma-fe

fix secret key failure

lint pipeline