Why not just add this to the footer for the core so it can be available everywhere? Otherwise we'll find ourselves receiving requests for it to be on the Support Manager, and every other public facing plugin.

Additionally, the order plugin may need to be updated to set the client (on new registration only) to use the selected language during checkout.

A language-selector may be useful for every page, including for staff users. For example, when a staff logs in as a client they may want to see the UI in the client's language rather than their own.

This would require the language to be stored in the user session, in which case if a user selects language B, then logs in and their user language is language A, we should maintain the language B setting. This would require that we offer the language selector even on authenticated pages.

Why would we need to offer the language selector on authenticated pages? If we are a staff member authenticated as a client, couldn't we show the selector to staff only? In such a case, the language selector would only be visible on authenticated client pages when staff uses the "login as a client" feature.

Why would we need to offer the language selector on authenticated pages?

Because we must store the preferred language in the user's session. If the user is authenticated we should maintain this preference. So users must have a way to change their selected language (again, stored in their session) after being authenticated.

Plus, it just makes more sense to be consistent with language selection. Disappearing UX controls when a user authenticates seems like bad UI.

How often do clients change their language? Once they sign up, assuming they can select their language during checkout (this task), they are unlikely to need to change it again, ever. If they do need to, they can do so by editing their account. Always displaying a language selector clutters the UI unnecessarily.

The necessity for staff to see a language selector is due to requests to show the client area in the clients language to staff. But, not all staff will want to see it that way, hence the selector.

See attached screenshot, I imagine the language selector should look like this. In this case, the "Return to Staff Portal" link is off to the left.

Seems like the selector would need to be in the admin interface too, otherwise they will see the language they chose in the client UI when they go back to the staff portal.

Perhaps the option should not be displayed to staff who are "logged in as" a client if that is the case. I do not want this feature to have any impact on the staff interface.

Doesn't that behavior contradict the point of staff logging in to to the client UI to see what they see? I imagine staff may also want to test that clients see the language selector, or could tell them it's there if they were on the phone with them or something. It usually makes sense for UI changes like this to be consistent.

It's not a big concern that the language selector not appear when staff are "logged in as" a client, but I do agree that consistency across the client interface is ideal. However, I do not want to add any such selector to the staff interface If Staff change the language within the client area, it should be ephemeral, not saved for the client language, and not impacting the admin's language within the staff area.

Markup Attached

There will need to be 2 new Client Theme colors: Top Navigation Text Color, and Top Navigation Text Active Color, whose placement is indicated in the CSS attached. I still need to come up with default colors for the FOUR client theme, and other themes.