* initial support for block/mute
* hide blocked + muted content everywhere
* add info message for blocked/muted characteristics
* sort blocked list by most recent block first
* add 'blocked' message on channel page for channels that you have blocked
* cleanup
* delete unused files
* always pass mute/block list to claim_search on homepage
* PR cleanup
## Issue
4796 - i18n: Allow support for string overloading (multiple contexts)
## Approach
- Minimal code and process change.
- Handle on a case-by-case basis when reported by translators.
- Split the affected key in the string json by appending the context.
- Translators need to be aware of the new format and not translate context itself. Code is added to detect bad translations and will revert to English.
Sample in json:
"About --[About section in Help Page]--": "About",
"About --[tab title in Channel Page]--": "About",
Sample in client code:
title={__('About --[About section in Help Page]--')}
- "--[ ]--" was chosen as it's unique enough (unlikely for real strings to use it) and hopefully not that distracting in the client code.
- In the key itself, spaces are allowed after the string (i.e. before '--[') for neatness. It will be trimmed by the system.
## First example
"About" is used in 3 places:
- Channel Page
- Help Page
- Footer (in Odysee branch)
For Russian, the word "About" is "O" and is usually not used standalone, but requires something behind it. A translator said so, and seems to be the case in other sites as well.
"O xxx"
"O yyy"
## Other languages
For other languages that are not impacted, they can just clone the same translation for each of the split keys, just like in English.
## Possible enhancement in Transifex
I see that Transifex's API includes a `context` entry. It might be possible to move the context-metadata there during the upload, so translators will never see the "--[]--" messiness (it will be shown as "Context: xxx" in the Transifex GUI).
I'm not sure how to test the Transifex side, so I did not investigate further.
## Issue
When navigating back and forth between a File and Channel page, the back-action will be laggy (no response) if the channel contains a lot of comments and is in the midst of resolving them.
## Changes
The "full" fix would be to batch-load comments, as this would improve the performance of fetching both Channel and File comments. For now, this commit focuses on the Back action problem only.
Skip fetching comments by not mounting 'ChannelDiscussion' until the tab is selected. I couldn't find anything in the Reach UI documentation on how to not render inactive `TabPanel`s, so I used the straight-forward state method.
## Issue
Closes 3964 `Add Youtuber info to file page`
## Changes
(1) Refactor the YT-info query into `YoutubeBadge` component.
(2) For the File Page case, don't show "- last sync <date>" since the date has nothing to do with the file.
## Test
[x] YT Channel page
[x] YT Channel's claim page
[x] Non YT Channel page
[x] Non YT Channel's claim page
[x] No channel (anonymous) claim page
[x] Various RENDER_MODES
