Allow language switcher to change language without losing user data

[domoscargin]

What

The default language switcher uses links. This has the potential to cause issues when we want to persist form data that a user has entered before switching language.

Explore two options:

1. Default the language switcher to links, but allow the use of buttons styled as links instead.

Since the action to a user is still to navigate to a different page, we think the consistency of the link style is preferable to ensuring that buttons look like buttons.

This would allow services to submit a page form and have access to the form data without using JavaScript.

2. Provide a JavaScript hook for clicking a language

Allow users to specify a callback for custom behaviour when they click a language.

Who needs to work on this

Developer
Accessibility specialist

Who needs to review this

Developer
Accessibility specialist

Done when

• Languages can be selected without navigating away from the page

[TheOnlyOrchid]

I've spiked option 1 here, in case it is useful to you: https://github.com/TheOnlyOrchid/govuk-frontend-language-switcher

It keeps the default language switcher behaviour as links, but allows individual language items to render as buttons styled as links. This lets a service submit the current form data, plus the selected language value without requiring javascript.

I also added tests for the behaviour, and in general tried to keep my code in the same 'shape' as other components.

I do apologise for potentially stepping on your toes, I started work on this before you marked that you were working on it.

I have no expectations that this is perfect, but I thought it might be useful as a reference or starting point. I'm happy to adapt, close, or leave it depending on what would be most helpful.

[domoscargin]

Hey @TheOnlyOrchid - thanks for this - no need to apologise!

It's not immediately obvious, but if you look at the "Projects" area on this page, you'll see this issue has been added to our project cycle board, which means we're actively working on it - so we'll be handling implementation ourselves rather than building on an external spike.

In general, I'd say the most valuable contributions for us are things that users discover in their use of the design system and govuk-frontend and need to fix. For that reason, we'd expect almost all of our external contributions to come from folks who work in public sector digital roles who have research to give, or problems they've encountered we haven't identified/prioritised.

[TheOnlyOrchid]

Alright! Thank you for the insight, I misinterpreted the structure. I wish you the best!