--- Issues:
(1) #-2669: Page does not restore to top when navigating new tags.
(2) "Encountered children with the same key" error (duplicate entries shown).
https://github.com/lbryio/lbry-desktop/issues/4367#issuecomment-645449206
--- Changes:
(1) Ignore the history if it's a new query (i.e. explicitly clicked). The BACK history will still behave as normal (doesn't reset to top).
(2) Previously, the `page` variable will continue to increment as you scroll and stay within the page (e.g. Trending vs New, or clicked another Tag). As you move between queries, we hit a scenario where `page` is significantly under or over the latest retrieved `claimSearchResult.length`. This messes up the rest of the code.
Fix by correcting the value of `page` according to the current `claimSearchResult.length` when necessary.
--- Issues:
(1) #-4394 add persistence to new support modal.
(2) Should collapse the custom field when presets are selected.
Even though the Send button repeats the amount for Tip, it's still confusing to see both the Preset being active and Custom numeric field visible.
(3) Missing localization tags.
Implementation:
- The code is placed in <VideoJs> instead of <VideoViewer> as we need to control the video itself. It's more self-contained here, rather than trying to pass refs around between parent and child.
- useState cannot be used as it will cause a re-render when the hint it clicked and dismissed. The DOM is used to hide the button.
--- The bad scenario:
A less popular tag like 'kanji' yields only 23 results today. The code continues to increase the page count. We'll either see some blank page glitches at the bottom, or repeated entries being shown.
--- The fix:
Assume that an unfilled page means "no more results" and stop incrementing the page. This seems true based on empirical evidence.
If you are at the bottom and you hit the UP_ARROW key one time, the logic still thinks we are at the bottom, despite the component has clearly moved. Similar to the issue noted in the previous commit, this causes the page to increment incorrectly.
My wild guess is that the previous logic depends on the css height, so it might got broken due to css changes. Hopefully the new calculation is more robust and works for all cases.
---The bad scenario:
If you're at the bottom and you go up using UP_ARROW or HOME key, the coordinate is still at the bottom if we service the callback immediately. This causes 'contentWrapperAtBottomOfPage' to be true and we ended up incrementing the page unnecessarily (even for searches that no longer yield any extra results).
---Fix:
Fix by adding a delay. The value can probably be fine-tuned further.
---The issue:
When switching between tags, the selector defaults back to Trending even though you had another option already selected.
---Changes:
- 'orderParamUser' will store the last user state persistently. The persistent state is also made unique for each page (i.e. Your Tags and All Content will be unique).
- If the parent component passes in a specific order, that will be respected and will also become the new persisted value. One example is "Your Following", where it always starts at 'New'.
- Handled navigation history correctly
The test case:
- Enter "Your Tags" (assume start at 'Trending')
- Click 'New'
- Click 'Top'
- Back
- Back (it should return to 'Trending')
As the top page history does not have any "?order=" value, we ended up with a no-op for the last Back. 'orderParamEntry' is added to handle this.
Two issues:
1. Values not marked with __()
2. Split sentence.
For #2, it seems like there are translations that don't make sense when combined, because the values are being translated independently from full sentence in Transifex. Decided to just make it full sentences.
The MDE used in the "new" section has a parent width parameter to limit itself, while the MDE used in the "edit" section didn't.
Fix by limiting ".comment__body_container" to 80%, which takes into account the space taken by the author's avatar. This feels a little bit dirty since it's hard-coded. If there's a way to calculate the avatar width from here, it will be more robust.
Removed space to sync the text "LBRY takes privacy and choice seriously. Just a few questions before you enter the land of content freedom." with that from app-strings.jsx
Currently, the input field goes off-screen if the read-only prefix is too long.
Given that the prefix is read-only, the user probably knows what the prefix is from context. e.g. In the case of the Repost Modal, the prefix is repeated in a selection field above. So, it's probably ok to just truncate the text to an ellipsis.
The input field is the more important one here, so giving it 60% width when truncation is needed.
Implementation:
- <StatusBar> listens to 'update-target-url' and will show/hide itself as needed.
- Handled the display of "lbry://" protocol.
CSS:
- The colors chosen should work on both Light and Dark Theme.
- The delay is necessary to avoid blinkies when the mouse is moving around.
#4259
Fixed color issues that were making things hard to read:
- selected text color, including inline code.
- HTML tags
- Horizontal rule not visible in Preview mode. While at it, I changed the color in Edit mode as well as syntax highlighting.
- blockquote (was gray over gray)
Attempted to fix uneven margins between top and bottom for inline-code and codeblock. Also, removed the extra margin to make it more nice and cosy, instead of far apart.
-- "/wallet" --
I believe this is a link and comes from redux, and shouldn't be translated.
-- "%message%" --
No point sending a variable-only to the translators -- the intended replacements are translated correctly.
-- "%name%" --
Unused.
-- "Something something something..." ---
Unused.
-- Obsolete strings (replaced by better string) --
"You are not able to see those stats right now. Make sure you are signed in with the correct email and have data sharing turned on."
"You are not able to see this channel's stats right now. Make sure you are signed in with the correct email and have data sharing turned on."
"There are no stats for this channel. Make sure you are signed in with the correct email and have data sharing turned on."
The only issue I have with this as a translator is that I have no idea what this sentence is about, as both chunks are variables. This fix is more for clarity.
#4239
Concatenating strings directly assumes that all languages have the same structure as English, which it is not. This fix allows translators to move the tokens around per their language/grammar requirements.
#4239
language and API consts
improve customization
custom homepages
get config from .env.default
custom title and logo
small changes
add pinned item to sidebar
rebase?
Technically, the other modes can have a quick-action button as well, but for now it's not implemented since it's unlikely to be used.
The first usage will be to house the "toggle markdown editor" button, but it can be used for anything. The caller will handle the action.
It will be located at the upper-right, which is a better place for such a button. Putting the "toggle markdown editor" button on the bottom seems too far away and seems to make the 'Done|Cancel' area too busy/cluttered.
--- Problem (#4173) ---
Messages under <i18nMessage> weren't localized although the translation is available. However, the tokens for these messages are localized, causing a mixed-language final string.
--- Fix ---
It appears that the original message (instead of the localized) was used in the token-substitution process.
Problems solved (second attempt):
A. Small typo for <div className="card__title card__t itle--deprecated"> (extra space in the word **t itle**)
B. More details about problems with languages:
1. The word blocked has two forms in other languages (one for plural and one for singular) and therefore must be put together with channel and channels words. Currently it can be translated in only one form.
2. In the case there are no blocked channels there is no need to show the 0 value and is more elegant the message 'You do not have blocked channels'
3. The link to manage the channels should not be visible in the case that there is no channel blocked, because there is no channel that need to be managed.
And about your statement: "Your change would make it harder for other languages to change this sentence."
It's quite the opossite, it's very clear and easy. They just have to translate (with examples in Romanian):
'%count% %channels%. ', (leave it as it is)
'You don't have' = 'Nu aveți'
'You have' = 'Aveți'
'blocked channel' = 'canal blocat'
'blocked channels' = 'canale blocat**e**' (see the change for plural forms for the word blocked, not only for channels word?)
I hope this time I explained better the need for the changes.
Thanks
Messages displayed:
Case with 0 blocked channels: You don't have blocked channels. (No Manage button displayed)
Case with 1 blocked channel: You have 1 blocked channel. **Manage** (manage link)
Case with 2 or more blocked channels: You have 2 blocked channels. **Manage** (manage link)
The best candidate is `aria-label`, followed by `description`.
Most of the existing elements already have these defined, so try to route it as the tooltip instead of having to explicitly define tooltips everywhere through a redundant `title` or <Tooltip> tag.
Minor side-effect:
This will cancel off any effect from a parent <Tooltip>, i.e. might confuse future developers who are trying to do "<Tooltip><Button></Button></Tooltip>".
The class was only returning a localized string for 'years' and 'months'; English was used for the rest.
- Fixed by handling the remaining cases.
- New strings were added (1) so that they will all be consistent language-wise until the translators handle them all (2) allows for cleaner code through variable re-use (%duration%).
Changed "Your video may not be the best format. Use MP4s in H264/AAC format and a friendly bitrate (720p) for more reliable streaming." to "Your video may not be the best format. Use MP4s in H264/AAC format and a friendly bitrate (under 5 mbps) and resolution (720p) for more reliable streaming." and changed the two times it says this "For video content, use MP4s in H264/AAC format and a friendly bitrate (720p) for more reliable streaming." to "For video content, use MP4s in H264/AAC format and a friendly bitrate (under 5 mbps) and resolution (720p) for more reliable streaming."
