![](https://lemmy.ml/pictrs/image/24716431-8f92-417a-8492-06d5d3fe9fab.jpeg)
![](https://lemmy.ml/pictrs/image/waqyZwLAy4.webp)
No that’s not merged yet, still needs more feedback from plugin devs.
Lemmy maintainer
No that’s not merged yet, still needs more feedback from plugin devs.
The key is refreshed after 24 hours so it will work if you wait a bit.
There were optimizations related to database triggers, these are probably responsible for the speedup.
No that’s a completely different issue.
Yes I have more time available than expected, at least for now. And whenever I don’t program for a while, I get a strong urge to write some code so I can’t stop myself.
Yes I have more time available than expected, at least for now. And whenever I don’t program for a while, I get a strong urge to write some code so I can’t stop myself.
True there are a lot of issues related to notifications. I will see what I can do.
Here is the relevant issue, but no one is working on it currently.
None of that matters if Mastodon doesnt implement these suggestions or standards. And from past experience its extremely unlikely that they will. Thats why I think its best to ignore what Mastodon does, its not our concern how they decide to render things.
It was always normalized, but recently there seems to be more backlash from maintainers.
We only do major versions around once a year so those could still be named, while using numbers for minor versions. Lemmy is more user-facing than react, so it would make sense to have a more user-friendly versioning.
We didnt make any changes to the Lemmy version running on this instance during the past week. So it must be something else…
The problem is that a server could very easily lie and claim to have captchas when it really doesnt.
I see now, if an instance has any site languages configured those will be applied for new users. You can see it in /api/v3/site
field discussion_languages
. However both lemmy.world and lemm.ee return all languages there.
Edit: Im removing this as part of the PR to set new user languages from accept-language header, it doesnt make sense anymore with that.
Yes contributions to improve this interface would definitely be welcome.
Right my_user.discussion_languages
is the correct one. And it being empty means that all languages are enabled (to avoid storing lots of unnecessary db rows). Im testing with a new account on ds9.lemmy.ml and can see posts marked as English without any problems.
I cant really how such a problem could happen and only affect those specific instances. Can you check through the api which languages are enabled on a new account? The info is under /api/v3/site
in the field discussion_languages
, it should contain numbers from 0-183 which are all the language ids.
I confirmed this just now, when registering a new account all discussion languages are enabled. However this isnt properly indicated in the lemmy-ui user settings.
When you signup, all languages are enabled by default. I believe it was like this since the feature was first implemented. I recently made a pull request so that languages are automatically configured from accept-language
header.
Its okay, everyone is wrong about some things.