-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement new UI for switching languages #12544
Conversation
I have tried it out on my machine: great progress! (Please tell us when you're ready for UI feedback :) ) Does the list represent the priority sequence in which you plan to implement the other points? Re the Content-Language header: I would suggest not to do a work-around for missing It would be great if you could provide screenshots of the current implementation state, it's both great for documenting the progress as well as it allows others to quickly peak at the current stage. |
The list is in a rather random order - it's a memory dump where I wanted to write things down before I forget them. I believe that all or almost all of them need to be implemented before the feature is shippable. Is there anything that you think is likely to spark some longer discussion and that should be implemented sooner rather than later?
Here is a screenshot of the state as of today: It shows a part of the A design question for @folletto: when I see the |
A step back for the rationale: it was bold to match the button styling, not the site dropdown styling. I agree there's a mismatch there tho, as the site dropdown doesn't adjust weight to align with buttons, so it's probably something to be reviewed more broadly as there's an existing incoherence there. Given we're "in between", I'm ok with either option. If you feel the normal weight one is better, go for it. :) |
} ), | ||
} | ||
|
||
constructor( props ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like you could use ESNext property initialisers instead of this constructor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -0,0 +1,127 @@ | |||
import React, { PureComponent } from 'react'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing an External dependencies
docblock
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
d7815ed
to
728ad4e
Compare
}, | ||
{ | ||
action: 'confirm', | ||
label: translate( 'Select Language' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi! I've found a possible matching string that has already been translated 60 times:
translate( 'Select a language below' )
ES Score: 10
See 1 additional suggestion in the PR translation status page
Help me improve these suggestions: react with 👎 if the suggestion doesn't make any sense, or with 👍 if it's a particularly good one (even if not implemented).
Today's update:
New problem: in order to be able to react to changes in the user settings, and to do that without using legacy components like the As a rather ugly temporary workaround, I now subscribe to |
728ad4e
to
f8bcedb
Compare
Added a list of suggested languages: It's based on browser preferences, i.e., on What remains to be done on this feature:
@folletto What do you think are best options for making the suggested language list responsive? Show limited number of suggestions on one row and hide the ones that would overflow? Convert the list into a popup menu when the viewport width is small? ( |
</div> | ||
</div> | ||
<LanguageChooserModal | ||
isVisible={ this.state.open } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the LanguageChooserModal do anything if it's not visible or own the visibility in some sense? If not, we might take the isVisible out of it and check it here to simplify the component and avoid creating it at all when it's not visible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The LanguageChooserModal
internally uses the <Dialog>
component which owns the visibility state. It's supposed to be used in a 'declarative' way - just unconditionally render a <Dialog isVisible={...}/>
and it will figure out whether to render something or not.
Before this feature is ready to merge, I'll need to do some performance tuning on this: to avoid creating the whole dialog contents in cases where it's not going to be rendered anyway.
f8bcedb
to
aacd47a
Compare
aacd47a
to
3174adf
Compare
Rebased this PR to latest master, where #12714 just got merged. |
Removed usages of valueLink and checkedLink from client/me/account/main.jsx and replaced them with value/checked/onChange properties. Also, stopped using valueLink method from me/form-base and the LinkedStateMixin. Replaced them with methods on the Account class that directly work with the userSettings module and the component state. This will come handy when Reduxifying the component - all the method calls will be straithforwardly replaced with selectors and action dispatches. It also comes handy for PR #12544 that introduces a new LanguageChooser component. This component won't have to support the dual API with both value/onChange and valueLink, but will need to support just one. After this PR, doing the same change in other client/me subdirectories should follow.
3174adf
to
2a60256
Compare
Current status:
@akirk @folletto @ehg I guess I'm ready for a design review and code review of the new language picker. There are currently 5 commits in this branch that I indend to merge as separate PRs. The first version of the chooser dialog will have two tabs with "Popular Languages" and "All Languages", there will be no suggested languages and no division by territory. These will be followups after the basic version is accepted and merged. I'll be now working on Reduxization of the |
Ok go ahead for the separate PRs. In general the design looks good. I've just a secondary note that the "button" should be entirely clickable, and should highlight similar to the standard buttons on hover, not just "Change". Sorry if it wasn't clear from the mockups. |
2a60256
to
6cad6b8
Compare
Removed usages of valueLink and checkedLink from client/me/account/main.jsx and replaced them with value/checked/onChange properties. Also, stopped using valueLink method from me/form-base and the LinkedStateMixin. Replaced them with methods on the Account class that directly work with the userSettings module and the component state. This will come handy when Reduxifying the component - all the method calls will be straithforwardly replaced with selectors and action dispatches. It also comes handy for PR #12544 that introduces a new LanguageChooser component. This component won't have to support the dual API with both value/onChange and valueLink, but will need to support just one. After this PR, doing the same change in other client/me subdirectories should follow.
6cad6b8
to
474716b
Compare
Removed usages of valueLink and checkedLink from client/me/account/main.jsx and replaced them with value/checked/onChange properties. Also, stopped using valueLink method from me/form-base and the LinkedStateMixin. Replaced them with methods on the Account class that directly work with the userSettings module and the component state. This will come handy when Reduxifying the component - all the method calls will be straithforwardly replaced with selectors and action dispatches. It also comes handy for PR #12544 that introduces a new LanguageChooser component. This component won't have to support the dual API with both value/onChange and valueLink, but will need to support just one. After this PR, doing the same change in other client/me subdirectories should follow.
Removed usages of valueLink and checkedLink from client/me/account/main.jsx and replaced them with value/checked/onChange properties. Also, stopped using valueLink method from me/form-base and the LinkedStateMixin. Replaced them with methods on the Account class that directly work with the userSettings module and the component state. This will come handy when Reduxifying the component - all the method calls will be straithforwardly replaced with selectors and action dispatches. It also comes handy for PR #12544 that introduces a new LanguageChooser component. This component won't have to support the dual API with both value/onChange and valueLink, but will need to support just one. After this PR, doing the same change in other client/me subdirectories should follow.
Removed usages of valueLink and checkedLink from client/me/account/main.jsx and replaced them with value/checked/onChange properties. Also, stopped using valueLink method from me/form-base and the LinkedStateMixin. Replaced them with methods on the Account class that directly work with the userSettings module and the component state. This will come handy when Reduxifying the component - all the method calls will be straithforwardly replaced with selectors and action dispatches. It also comes handy for PR #12544 that introduces a new LanguageChooser component. This component won't have to support the dual API with both value/onChange and valueLink, but will need to support just one. After this PR, doing the same change in other client/me subdirectories should follow.
b597d56
to
94cb718
Compare
}, | ||
{ | ||
action: 'confirm', | ||
label: translate( 'Select Language' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi! I've found a possible matching string that has already been translated 60 times:
translate( 'Select a language below' )
ES Score: 10
See 1 additional suggestion in the PR translation status page
Help me improve these suggestions: react with 👎 if the suggestion doesn't make any sense, or with 👍 if it's a particularly good one (even if not implemented).
6cdbc0a
to
01b5936
Compare
Suggestion: use the Autonym Font for the language names to prevent ܕܥܒܪܸܝܛ |
Added a new LanguagePicker component which can be used as a form element to change the interface or site language. On click, the component opens a LanguagePickerModal dialog with UI suitable for finding and selecting one of 135+ languages.
When dispatching saveUserSettings, optionally add custom onSuccess and onFailure actions. These will be dispatched instead of the default ones (i.e., the initiator action with meta attached).
Created a LanguageButton component that shows the interface language in every sidebar (shown next to the Help button) and allows to change the language on click.
Display list of suggested languages based on 'navigator.languages', i.e., on browser settings. If the 'navigator.languages' feature is missing from the browser, detect that fact and don't show the suggested list in that case.
01b5936
to
5ab51cb
Compare
Looks like a great idea, thanks! I'll definitely try the font out. I'm wondering how the font glyph look like design-wise. Also, I'm a bit worried that the project is explicitly marked as unmaintained. @yoavf do you have any direct experience with the font? Have used it on any project? |
Update: using the new Redux |
Nope, no personal experience. I was thinking it was used on Wikipedia, but I've just checked and this doesn't seem to be the case. Feel free to ignore it then :) |
Closing this PR as all related changes were moved to separate smaller PRs under the Language Picker Project |
This is a PR for my trial project described in my post on the i18n P2 blog (internal ref: pxLjZ-3EJ-p2).
The main part of the effort is implementing a new language picker component (internal ref: p4TIVU-5np-p2).
A big task with many subtasks:
LanguageChooser
component intended to replace the existingLanguageSelector
. Its design is based on theSitesDropdown
component.LanguageChooserModal
dialog that opens after clicking the "Change" link in theLanguageChooser
. The design is based onEditorMediaModal
. A tab bar with language groups and search, filtered list of languages to choose from, and a button bar with "Cancel" and "Select" buttons.LanguageChooser
on the/me/account
page.LanguageChooser
on themy-sites/site-settings/form-general
page. This will need several improvements to the component:valueLink
prop, support also avalue
/onChange
variant. Or get rid of thevalueLink
inme/account/main.jsx
. That might be more future-proof, asvalueLink
is deprecated. (valueLink
is being removed in PR Removed usages of valueLink from client/me/account #12729)disabled
stateeventTracker
) into the componentLanguageChooser
. It's displayed when settings data is being loaded.LanguageChooserModal
README.md
for the new componentsDisplay the explanation text side-by-side with theabandoned, displaying under the component for consistency.LanguageChooser
(if the viewport is wide enough)LanguageSidebarChooser
component that will be displayed in sidebarsLanguageChooserModal
. The suggestions will be based on the browser language settings.navigator.languages
For browsers that don't supportDecided to support onlynavigator.languages
(it's a new experimental API, supported only by Chrome and Firefox atm, according to MDN, find some fallback - probably some server REST API endpoint that reads theAccept-Language
header.navigator.languages
now and maybe make/locale-guesser
smarter sometime in future./locale-guesser
API endpoint. Result: using geolocation to select the default tab.config/_shared.json
file, or whether to query it online (see below)AsyncLoad
in future.When a language name is too long and doesn't fit into the column, add a "fade-out" effect to make the clipping look good.(turns out this is not needed when the column count is responsive -- there's always enough room for all existing language names)config/_shared.json
. There are a few errors. (moved this task to an independent PR: Update/normalize language names #12714)name
. Converten - English
toEnglish
.A related task that will probably be an independent PR: avoid reloading the whole page after a language is switched. Just trigger a React rerender with the new language. (Moved to #13712)
localize
HOC fromi18n-calypso
support this? Will the value of the injectedtranslate
property change?translate
props changes? Or will it be blocked by someshouldComponentUpdate
implementation? Or a wrong/missingcomponentWillReceiveProps
?client/components
, orclient/blocks
orclient/components/form
? Result: It should beclient/component
- it's a "dumb" component that only renders what it's passed in props. To be eligible to be ablock
, it would need to connect to the app state by itself.LanguageSelector
component and replace it completely with theLanguageChooser
, maybe even reusing the name.The
LanguageChooser
uses thelib/user-settings
module that uses a legacy, event-based approach to data. Converting this module to Redux would be great.lib/user-settings
into a thin wrapper over the Redux APIlib/user-settings
lib/user-settings
module