Conversation
877dd40 to
d72e981
Compare
common/locales/de.json
Outdated
| "autoPauseAtSubtitleStart": "Am Anfang des Untertitels", | ||
| "autoPausePreference": "Auto-Pause", | ||
| "autoPausePreferenceHelperText": "Aktiviert keine Auto-Pause", | ||
| "seekDuration": "Amount of seconds to skip fowards / backwards when seeking with respective shortcuts", |
There was a problem hiding this comment.
This label is pretty long - can we shorten it?
"Seconds to skip forwards/backwards when seeking with respective shortcuts"
There was a problem hiding this comment.
That's the shortest I could think of for now
There was a problem hiding this comment.
Seconds to skip when seeking forward/backward or
Seek duration (sec) ?
Now what you say it, I'm thinking it'd be better to move these shortcut related settings from MISC into KEYBOARD SHORTCUTS. This way they're gonna be more discoverable by the users and won't need as much helper text because both shortcut and the setting will support each other with context. I'm not sure if there would be any technical challenges with migrating the settings like this?
There was a problem hiding this comment.
Yeah I think that would be the ideal solution. Another input field directly under the keyboard shortcuts for seeking left/right.
Similarly, it would make sense for "Always play after invoking 'Seek to beginning of current/previous subtitle'" setting to go underneath the "seek to beginning of current/previous subtitle" shortcut setting.
Ideally there is a solution for both binds. The problem is that we are rendering the keyboard shortcut settings in a for loop over keyBindProperties. First idea that comes to mind is to add a JSX component field (additionalControl or similar) to KeyBindProperties that defaults to null. Then we can just modify keyBindProperties for the two keyboard shortcuts we actually care about, without having to modify the for loop itself with special case logic.
There was a problem hiding this comment.
Ok I've pushed the latest commit feaafc7 adding this. I've had to move const {...} = settings init because keyBindProperties now depends on settings.seekDuration
Let me know if you're happy with this approach and I'll tidy up the rest of the PR with the other settings
There was a problem hiding this comment.
@artjomsR Sweet, yeah the code looks good. UI-wise I think I would want the new text field have the same width and be aligned with the keyboard binds.
f9e76c2 to
feaafc7
Compare
c0f38bf to
d9facde
Compare
d9facde to
0a027e4
Compare
51aae2d to
2402592
Compare
2402592 to
81cdb04
Compare
|
@artjomsR Thanks! Really great work and I appreciate you entertaining my suggestions. Yes I agree that with the alignment being all the same it is difficult to tell the keybinds apart from the additional settings. Maybe there is a solution to this while keeping the alignment - in my mind the alignment needs to be the same. |
| "autoPauseAtSubtitleEnd": "在字幕末尾", | ||
| "autoPauseAtSubtitleStart": "在字幕开头", | ||
| "autoPausePreference": "自动暂停首选项", | ||
| "autoPausePreferenceHelperText": "不启用自动暂停。设置启用自动暂停时暂停的首选项。", |
There was a problem hiding this comment.
Unfortunately we need to keep this key because currently all versions of the extension share the same loc file.
|
Hey just one more change and I'll merge ^^ |
It'll be easy to change later since it's contained in KeyBindRelatedSetting. And most of these settings stand out anyway since they have a different input type
Just revert the strings in the .JSON files, right? (Even though they won't be used in code). I'm away from my pc today and will try to do it tomorrow, but feel free to revert then if you wish to merge it quicker :) |
ca05243 to
ad5613f
Compare
|
Ok done |
|
Sweeeet! |




Implements #287
I've tested firefox and chrome extensions and the local player. I didn't change the android version
Also, when I was generating translations, I couldn't run
node ./scripts/loc/merge-loc-from-en.jsas I was getting