-
Notifications
You must be signed in to change notification settings - Fork 513
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
fix: redesign of language selector #2839
fix: redesign of language selector #2839
Conversation
Implement redesign of language selector and related interactions. This also includes a change to how the underlying grid is implemented. Part of #1486
Note: I am trying to understand what exactly is making the test above fail. If anyone has a hint, I am all ears :) I think it might have something to do with the language selector, but not 100% |
An interesting thing I notice is if I add
So it seems like it is loading That seems misleading though because, even if I change the lines 59-62 to the following:
the test still fails |
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.
Those headless tests are weird!! I still can't explain how it could be that you're suddenly on that "Flex" page. However, if you run:
TESTING_OPEN_BROWSER=true yarn test:testing headless
you'll notice the same strange thing as you see in responsive mode
when you visit http://localhost:5000/en-US/docs/Learn/CSS/CSS_layout/Introduction/
I don't know why puppeteer is having a problem with that page and why it doesn't happen in a regular browser. But if you scroll down you'll see that the page is very messed up and perhaps that's causing something that expect-puppeteer
can't handle. It's like it's freaking out. After all, the toMatch()
function isn't trivial. It's based on finding things you can find with Cmd-f.
There are many other things that I think we should discuss in this PR.
We should, first of all, remove all the unrelated changes that slipped in that have nothing to do with the language selector. They deserve their own PRs with discussions.
The thing I don't like is that the "document footer" has lost its styling. We worked hard to come to the conclusion and design that the document footer would look different and "stand out" more from the last couple of paragraphs of text in the document:
after
Basically, I prefer the way it looked before. It made it more obvious that this was functionality stuff and not part of the article text.
The other thing I don't like is that switching to English doesn't set the cookie. It's an imperfect thing that changing language with the drop-down actually sets a persistent cookie but it's so very convenient. And it's understandable because you're very deliberately doing something. Simply clicking a link is questionable if it's very deliberate. But after all, it's part of the "change language" functionality and I think I would be disappointed if I have to click English a second time when I've already pressed it once.
Another thing I don't understand is; Why is the "Change language" button an outline one? |
I agree that it is more practical to make all buttons the same and select them with Note: PRs that create an entire feature at once are dangerous. You could do the exercise of doing PR in Javascript only, CSS only, JSX / HTML only and so on. It is not correct, however, that the CI creates problems that are not related to the files touched, it is like the speech of pure functions, performance problems should not arise in changes to the template (unless there is a direct correlation and I do not I see) 👎 |
That is a fair point and I was not entirely happy with it. Here is what it looks like now: On EnglishOn French |
Yup, but it was my understanding that that is what we decided to do for now. Perhaps this changed? |
Addressed. |
And the tests now all pass 🎉 |
There's another problem which needs to be addressed. It used to be that the language switcher (which triggers a |
I think the unrelated changes that became part of this PR needs to be spun out into its own PRs. If you do that, you won't necessarily need to edit this branch because once you |
Why does the "English" choice have to be a hyperlink? If you stumble into a Japanese page, do you really need the English option displayed separately from the drop-down? Only having the drop-down fixes all the problem mentioned in the paragraph above. |
Would it be an option to not change how things are working today for Desktop and only on mobile make use the little "language icon" that scrolls to the bottom of the page? On Desktop, where screen real-estate is aplenty, I don't think there's much value in stuffing it to only be accessible at the bottom of the document. |
Regarding this I don't know if it is a correct choice but at this point it could turn into a |
The idea was for it to be a quick and simple way to switch to English without changing your cookie. @escattone Thoughts? |
Like @schalkneethling said above, I also thought we had agreed within an earlier Zoom meeting that the "switch to English" link would be a convenience for those who'd like quick access to the English page without setting their |
I see that as well. That is unfortunate. Would it be disastrous if we not go via the router and instead do something like |
This Is probably more mothodic: I don't understand, but the React router doesn't go away because of the server side rendering? If it is used because of the select I would recommend to do the default submit which however triggers a navigation. |
@peterbe Also showing the language menu on non-English pages. Also, sending a GA event when a user changes language using the language selector. All events are bundled as
|
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.
I don't think the parameters to send to GA are correct. E.g.
eventCategory: "change language",
eventAction: `Changing from the current locale: ${locale} to ${localeURL}`,
eventLabel: "change-language"
I think it should be something like this instead:
eventCategory: "Language",
eventAction: "Change preferred language" | "Switch to English" | "Anchor to language choice"
eventLabel: "${locale} to ${translation.locale} on ${currentURL}"
That way, you can aggregate by the category first, and then by the action. And within each action you can then analyze all the specifics.
Look at the examples on https://developers.google.com/analytics/devguides/collection/analyticsjs/sending-hits#using_the_ga_command_queue
And look at the descriptions in the table on https://developers.google.com/analytics/devguides/collection/analyticsjs/events#event_fields
I also think the non-en-US content should have both widgets in the top bar.
- "View in English"
- (anchor link) "Change language"
I know you mentioned we could let this simmer to build up events stats and then change it but I don't think it's realistic that we remember to do that. Let's get it right the first time if we can.
And the anchor needs to move as demonstrated in the screenshot.
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.
I think we should use the URL instead of just the locale.
And in one of the cases, a ga()
call never has a chance to execute because the browser will cancel all interactions as it changes the URL.
I collected a bunch of feedback into a "counter-PR" which solves these issues.
Feedback as a PR here: https://github.com/schalkneethling/yari/pull/294 |
feedback on language selector
@peterbe Not sure why the tests still fail, I ran |
Hmmm, now I am also getting |
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.
I carefully tested it in Chrome with the GA debug stuff. And with the SSR built pages. Works swimmingly!
@schalkneethling I see you requested a review from @fiji-flo too so I won't merge it. |
await expect(page).toClick("a.view-in-english", { | ||
text: "View in English", | ||
}); | ||
await page.waitForNavigation({ waitUntil: "networkidle2" }); |
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.
This line was the cause of #3116
Sorry. I should have caught that in review. You should only use a line like this when you depend on lazy-loading to come in. At least that's what I found when I worked on the headless tests for site-search.
Sorry for bringing this up, but why did you decide to move the language selector? Previously, it was at the top of the page, it was very convenient and UX-friendly, why move it to the bottom of the page? |
It's still at the top (top right-hand corner area). But now you click it to automatically go to the bottom of the document. |
@peterbe I meant why not move language selectbox itself to the top of the document, something like this? Currently it is extremely inconvenient to switch the language, usually on other websites you can switch language at the top of page. |
Excellent feedback! Thank you for sharing. Much appreciated. One of the reasons we implemented it the way we implemented it was based on A) that the drop-down widget was clunky on mobile and B) we hoped that it's relatively rare that you'd want to switch. And after all, next to the link that takes you to the bottom of the page, there's a "View in English" link for the translated pages. @schalkneethling Can you share your thoughts here please? |
Actually, you can completely remove the "Change language" button (leaving only eponymous label), and change the language immediately after choosing any other option. For example, something similar is done in the PHP docs, you can check it out yourself, for example, on this page https://www.php.net/manual/en/function.array-chunk.php |
* fix: redesign of language selector Implement redesign of language selector and related interactions. This also includes a change to how the underlying grid is implemented. Part of mdn#1486 * fix headless test * change let to const * changes based on review feedback * additional changes based on review * add key the li and fix grid row inconsistency * remove negative tabindex * update to latest implementation * fix failing headless test * fix failing headless test * add missing / at end of test URL * fix overall layout for desktop * updates to overall layout of top of document pages * update grid for standard aka non-document pages * correctly align lang toggle on mobile * handle all 5 possible states of breadcrumb-locale container * instrument view in English and change language links * also show language menu on non English pages * send GA event when changing language via language manu * changes based on review feedback * feedback on language selector * fix failing test * fix failing test * remove react import Co-authored-by: Peter Bengtsson <[email protected]>
The scrolling behavior is slow and very disorienting (and potentially bad for people uncomfortable with motions). Users still need to do this A LOT, because docs in their languages aren't complete (or can never be completed), and links in a tranlated page may point to a page in English even if the latter is translated (similar to content/issues/2665). Besides, even if they have translated version, people often switch back and forth to check the original text anyway (check if up-to-date, confusing translations, contributing, etc.). I would rather it be convenient and comfortable to switch than saving some space. However, other multilingual docs have already solve this in better ways IMHO:
Agreed. This may be a good solution if revert to old design. |
Implement redesign of language selector and related interactions.
This also includes a change to how the underlying grid is implemented.
This addresses a number of issues as listed below. The main issue is the language selector though. The layout has also changed some as we move towards https://www.figma.com/file/YYVJ8uqG8UFBBvQhdI7fxR/MDN-Web-Docs?node-id=709%3A0
Also note, because of the complexity of having the language selector in the footer, it is now under the metadata section. The metadata section has also been moved to be under the "See also" section and is no longer in a full-width bar.
You will need a clone of the
translated-content-rendered
repo and the following setting in.env
CONTENT_TRANSLATED_ROOT=/Users/username/repos/translated-content-rendered/files
With this though, you still need to be on a non-English page to see the language toggle and language selector. I am not 100% but, I think this might not be the case on production and there the language selector and language will always be shown if translations are available.
Mobile
Tablet
Desktop
Desktop - no language toggle
Language selector
fix #1486
fix #2478
fix #2755