Language selector

[michelle-rago]

We’re researching this potential standard. Research questions include:

• What’s the most effective way to help users find their preferred language on desktop and mobile (text, icon, browser language, etc.)?
• How should the number of languages offered impact the language selector?
• What order makes sense to users when there are many languages (alphabetized by English name, by non-Latin script, etc.)
• Where should the language selector be in relation to other utilities (e.g., login, search)?
• What should the role of the language selector be when only selected content is available in multiple languages?

[CNX-Inc]

I don't have any authoritative experience with language selectors but two things I'd encourage discussion on:

1. page-based vs. browser-based translations: e.g. even for websites that do have a language selector some users will, inevitably, use the built in translations service offered by their browsers.

2. language-specific domains: Most if not all language-specific domains are for spanish translations*. This seems counter productive on [at least] two fronts: (1) there aren't that many domains (<30 by my count) despite what I presume is a much higher occurrence of non-english services/guidance across the USG. (2) it seems to overly weight the experience for spanish-speaking users (e.g. we have a spanish version of "vaccines.gov but not in French or Chinese".

   • I wrote more about this here: https://www.linkedin.com/pulse/3-federal-dns-patterns-william-jay-huie-ehvye/?trackingId=owbZHuvCQHe7VPVNcDFvyg%3D%3D

   * I do realize Spanish speakers >> other language speakers but generally volume isn't the only indication of policy support

[thompsondc]

We use a subdomain for translations, where the www. gets changed to es., instead of using a directory path after the TLD (such as /en/ or /es/). That seems to be preferred by users, and also helps with mass-URL redirections or changes. We use automated means for translations, assisted by interpreters to fine-tune the translations.
I agree, that other languages would be ideal to support, but given resources and staffing, we are focusing on the most-common and working our way down the list of prevalence. The language selector we use is placed in the upper-right corner, which seems to be expected by users (just as the logo, which serves as a "home" link is expected in the upper-left corner).
I'll note that after reading your linked article, I agree with CISA and OMB, that language-specific domains should be strongly discouraged, along with other spell-check languages.

[CNX-Inc]

@thompsondc - that's interesting, I don't think I've seen that sort of "domain approach" before.

Playing with a few examples, I think it underscores some of the questions @michelle-rago mentions about "best practices" - e.g. (through probably because of my language settings) there's an interesting sort of interplay between the "translated domain" and the browser trying trying to give me "translation options"... I wonder how many users use the "Google Translate" from the browser (this is Chrome) vs. selecting the drop down.

[thompsondc]

Yeah. The browser developers have tried to meet the needs/wants of users; but it does tend to conflict. Because of our CMS, we use a plugin to do automated translations (which are slightly better than Google Translate does via Chrome); but then we have actual people translate specific words for a find/replace pattern throughout the site. It helps a lot to have a real person double-check and fix the nuances of language. Unfortunately, we don't have the staff or resources to cover more languages yet.

[CNX-Inc]

@thompsondc yea 👍 to it being tricky. Incidentally the USA.gov Español team did a great podcast on 'translation' - thought I'd share: https://podcasts.apple.com/us/podcast/celebrating-20-years-of-usagov-en-espa%C3%B1ol/id1537840592?i=1000631492400