Now that stricter API validation has been added, it will be necessary
to modify the target language in the client so the API will not fail
with a validation error.
This adds a new optional `sourceLang` parameter to the `notes/translate`
endpoint. If not set, the old behaviour is used, else this sets the
`source_lang` parameter to the DeepL API call which makes it use the
source language specified instead of using autodetection.
Changelog: Changed
Ref: FoundKeyGang/FoundKey#33
HTTP GET parameters are not to be specified in the requestBody but in
the parameters. This commit fixes that although admittedly it is kind
of a bodge and not perfect, but it is a start.
Changelog: Fixed
Per the @vue/compiler-sfc description on npmjs.com[1]:
> Note: as of 3.2.13+, this package is included as a dependency of the
> main vue package and can be accessed as vue/compiler-sfc. This means
> you no longer need to explicitly install this package and ensure its
> version match that of vue's. Just use the main vue/compiler-sfc deep
> import instead.
[1]: https://www.npmjs.com/package/@vue/compiler-sfc
Also remove the contributors list from about-foundkey (renamed from
about-misskey).
Some comments that referenced Misskey were also translated to English.
Closes: FoundKeyGang/FoundKey#141
GNU Social's follow request IDs are larger than the 128 character limit
of the follow_request.requestId column. This prevents follow requests
from GNU Social instances from being handled by Foundkey instances.
The solution is to make the requestId column larger.
Fixes FoundKeyGang/FoundKey#146
Add @Johann150 's patch from Misskey-Extras:
> Adds the "pudding" synonym to the custard emoji, and also newly adds regional indicator emojis to the list. These are displayed as letters if alone. Note that these become the national flags if put next to each other, so the behaviour might be confusing to some people.
Co-authored-by: Johann150 <johann.galle@protonmail.com>
Reviewed-on: FoundKeyGang/FoundKey#148
Changelog: Added
Turns out `getMany` doesn't work with the specific query used, so use
`getRawMany` instead.
Also fixup the predicate used in userInfo to use the correct field
names.
Exploiting this before should already have been rather difficult because you
would need to know or guess the notification's ID. It is also of relatively
low security impact.
Changelog: Fixed