Reactions will be backported to the vanilla
flavour, which requires all related settings to
be accessible from the vanilla settings page
rather than the glitch specific settings modal.
This adds an extra item to the local settings for
specifying the number of reactions shown in toots.
The detailed status view always shows all
reactions.
Too many reactions on a single post quickly get
spammy, so they are now sorted by count and only
the first MAX_REACTIONS number of different
emojis are actually displayed.
the maximum number of reactions was previously
hardcoded to 8. this commit also fixes an
incorrect query in StatusReactionValidator where
it didn't count per-user reactions but the total
amount of different ones.
* Add missing locale keys
Added missing translation keys to en.js to make translation easier and more complete.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
* Remove translation keys for explore
Have been added to vanilla in #2014
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
* Remove unused key
Sorry, originally worked on this on my custom fork, which has this key, before I decided to work on glitch.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Upstream does not have a column heading for “Posts and replies”, but the
text itself exists in a similar context, so re-use that translatable
string so that we can use upstream's translations.
Conflicts:
- `README.md`:
Discarded upstream changes: we have our own README
- `app/controllers/follower_accounts_controller.rb`:
Port upstream's minor refactoring
When opening a page such as /web/timelines/home in a desktop browser, the
cursor was automatically placed in the textarea of the compose form.
When using the keyboard for navigation (using a browser plugin like vimium or
vim vixen, or just to hit 'space' to scroll down a page), you have remember to
leave the field before using that.
Since you only visit the page to write a new post some of the time, this PR
attempts to have nothing focused initially (and require the user to click or
e.g. use 'tab' to focus the textarea).
Tested:
* /web/timeslines/home no longer autofocuses the compose box
* pressing the 'n' hotkey still focuses the compose box
* clicking 'reply' for a post still focuses the compose box
* replying to a CW'ed post still focuses the compose box
* introducing the CW field still focuses the CW field
* introducing the CW field for a reply still focuses the CW field
* removing the CW field still focuses the compose box
* /web/statuses/new still autofocuses the compose box
fixes#15862
The smaller border is difficult to see for some users, especially
when the browser window was thinner, and so the unread border is at the
very left edge of the window.
