## Issue
656 Automatic language detection can't recognize de-DE as de
## Note
We do fallback to the main language, but seems like the code got lost ... not sure when, but probably during the CN/TW or PT-BR support. The refactor in 81e47300 still did that, but the refactor was reverted due to some compilation issue (should revisit that someday).
## Change
Put back equivalent code.
* Tooltip: add 'followCursor' and 'placement' option
When used on a `<span>` with short text but large empty area, the location of the tooltip was at the bottom-center of the area, which isn't ideal.
I think 'followCursor' should be the default, but making it optional for now to minimize testing.
Also added the 'placement' prop -- for the span case again, the mouse cursor is blocking the tooltip.
* View/Follower count: only use compact when > 10k
## Issue
Received complaints -- some people prefer to see full resolution.
## Changes
- As a compromise, we'll only apply the compact notation when the value is greater than 10k, with the exception of Tile View Count, where we'll always apply it due to space limitation.
- Also added Tooltip for Follower count.
## Fixes
- The string was always in 'en' locale in some instances, so it wasn't grouping up digits properly in Japanese (groups of 4), for example.
## Issue
When "Upcoming livestream" appears in a list, infinite scroll stops working.
## Cause
The difference between `mainEl.getBoundingClientRect().bottom` and `window.innerHeight` became slightly greater than 0.5, so it was deemed as "haven't reached the bottom".
## Change
Coincidently, I've been wanting to make the inf scroll load earlier (instead of after reaching the absolute bottom) to make the experience smoother, so added a 200px threshold, which is roughly the height of a tile. This gets us the new behavior while also fixes the original problem.
## Background
Per developer of `tus-js-client`, it is normal to occasionally encounter upload errors. The auto-retry mechanism is meant to address this.
While implementing tab-lock to prevent multiple uploads of the same file, 423_locked was used to detect this scenario. But 423_locked could also mean "the server is busy writing the chunk" (per discussion with Randy), so we kind of disabled the auto-retry mechanism accidentally.
Meanwhile, from a prior discussion with Randy, one of the chunk-writing duration took 3 minutes. Our current maximum of "retry after 15s" wouldn't help.
## Change
1. Given that tab-locking was improved recently and no longer reliant on the server error messages (we use secure storage to mark a file as locked), reverted the change to "skip retry on 409/423". This is now back to normal recommended behavior.
2. `tus-js-client` currently does not support variable retry delay, otherwise we could prolong the delay if the error was 423. Since we know it could take up to 3 minutes, and that we don't know if it's file-size dependant, just add another 30s retry and put a friendlier message asking the user to retry themselves after waiting a bit.
- activeChannelClaim is the comment creator, not receiver.
- doSeeNotifications marks a notification as "seen", and not "send a notification".
- Removed comments that are just explaining the syntax.
* Test out a horizontal scroll for upcoming (tile only for now)
* - add support for list layout
- add following label on home page
- clan up css and naming conventions
* Update header type + show only if scheduled streams are showing
Our current chunk size is 25,000,000.
Google and S3 documentation suggests the chunk size to be multiples of 256KiB. MongoDB too. We aren't using any of those, but I guess no harm doing the same. From the logs, the values "25,000,000" and "50,000,000" seems to be common.
`doError` supported either a string or object, and so far there are no instances where the object version is used, so this enhancement should be safe to do without affecting anyone.
## Change
For the object version, support an additional `cause` parameter that will be logged but not show in the GUI.
## Issue
Closes 627 account header doesn't refresh on sign up / log in
## Changes
Looking back at "[Header] Changes, fixes and improvements (#493)", noticed that old code was looking at `has_verified_email` instead of just checking whether an email exists. So, restored original code.
This does have a side-effect of the Logout button not showing any email address underneath it immediately after sign up (with the flow cancelled). But I vaguely recall it was that way previously. A refresh cleans it up.
Perhaps another `user/me` when leaving the Sign Up page can make everything in sync, but this PR simpler to test.
* Add a setting to hide scheduled livestreams from home/following
* Add a hide button in the scheduled stream header.
* Fix typo + make sure pref is synced
