In 2020, based on a survey of 8,709 consumers in 29 countries and territories in Europe, Asia, North and South America, language services consultancy CSA Research found that 76% of people who shop online prefer to buy products with information marked in their native language, and 40% would never buy anything from a non-native language website. Hence the title CSA gave the report "B2C: Don't Buy If You Can't Read It".
This reaffirms the importance of language support to enhance the user experience and drive user growth.CSA believes that local language support creates a more sticky consumer relationship and that a stronger, global brand can also significantly influence purchase decisions.
That's why John Yunker, an independent business consultant who specializes in product globalization consulting, has been collecting aggregated and analyzed language support for global brand websites for over a decade. He calls the language menu on a website or application (primarily a website) - the landing page and header menu that leads users to the localized version of the site - the "global gateway, and when a user opens a web page that is not in their native language, they will first look for this gateway to switch the language to their native language.
Vitaly Friedman, UX designer and front-end developer, editor-in-chief of the design site SmashingMagazine.com, has written a very detailed article, which looks at various approaches to implementing language selectors on existing websites and concludes with a very practical summary of language selector design principles.
"The Blue Book of Product Localization has been authorized by Vitaly Friedman to exclusively translate and publish the Chinese version of this article.
Let's say you've just arrived in Tokyo. With impatience (from a long journey) and excitement (from just arriving), you are ready to start your trip, but then your mobile card operator sends you an emergency alert telling you that your phone bill balance needs to be topped up urgently. Somewhat worried, you open your carrier's website, only to be redirected to the Japanese version of the page. You can't read Japanese, but there's no obvious option on the page to change the country you're in, nor do you see an option to change the language of the page.
Your traffic keeps dwindling and you try left and right between the page's automatic translation and your limited VPN options until your traffic runs out. The website does have a language picklist set up, however it is disguised between hidden symbols and mysterious icons that are just impossible to find at a glance.
Stripe has popups in the footer of web pages that allow users to jump to different country versions of the page Chances are you've had a similar experience. As designers, we can certainly make the language picklist more visible and eye-catching, however most of the time, the appearance of the web component is only one side of the issue.
When designing interfaces, we many times subconsciously incorporate our own personal assumptions, biases and expectations into our work. Of course, we can't take into account all exceptions and special cases, so we focus on the most common ones, resulting in a well-designed user experience that leads to user dissatisfaction due to certain circumstances.
In fact, all that is needed to solve this problem is to decouple the presets, allow override, and allow users to specify language options as they see fit. But before we dive into the design principles of language picklists, it's worth exploring what options are currently available.
A little detail about the language pick list
Usually, we know when we need to put a language picklist. Every multilingual website needs a language picklist, and this is especially true for public services and companies in countries and regions with multiple official/common languages. For globalized brands, organizations and the travel industry, as well as e-commerce sites that may pay for goods in various currencies and ship to different destinations around the world, it is also important to have a language picklist.
Hikvision has set up a language picklist floating layer on the right side of the web pageWhere should the language picklist be placed? Users of course have their own preferences. In my experience, when wanting to change country/region or language settings, the vast majority of users will immediately go to the top of the page, and if it's not there at the top, they will jump to the bottom of the page and look in the footer.
Country and region selection markers, flags (banners) work quite well, and if users don't see a flag, they will look for icons that represent a language in some other way - such as the earth or the 'translate' icon. When it comes to translations of articles or specific pages, users generally rely on the law of proximity and look for language options next to the article header.
The Lululemon website has a sidebar floating layer on the right side for selecting the currency to be displayed The language selection uses another dropdown menu However, when designing time, we need to consider a lot of complex details. Of course, the picklist can be located somewhere in the header or footer, but we can also auto-jump depending on where the user is, auto-detect the language based on browser preferences, or pop up a pop-up box asking the user to select a region first. Tools that can be used also include text labels, abbreviations, icons or flags, native or custom drop-down menus, preference panels, sidebars, switches, or separate pages.
You'll find that many of the above solutions have usability issues of their own; if we want to maximize communication accuracy and reduce ambiguity, we have to come up with an appropriate strategy to do a good job of language tagging, grouping, and displaying so that the language picklist is clear to the user, while also avoiding interfering with accessibility and automatic translation features working properly.
Let's talk about an obvious principle at the very beginning - but also be aware: auto-jumping can be helpful, but it causes more frustration and annoyance than it does good.
Avoid automatic jumping
Many websites will automatically jump based on the user's location (IP address) or browser language setting. However, just because a person is in Tokyo doesn't mean Ta is fluent in Japanese; just because a user's preferred region is the Netherlands doesn't mean they want their purchases delivered to the Netherlands; and if a user's preferred region is France and the site doesn't have a French version, the user will encounter pages in the default language, which is not necessarily the language they are most familiar with.
Without asking the user first, we can't confidently infer their preferences. But that's not to say we should avoid automatic bounces at all costs. If a user happens to visit a US site from Germany, it's perfectly reasonable to direct them to a German page. However, if a German user whose browser's preferred language is English visits a German-language site, that automatic jump to that site's UK or US English page can be confusing - although in some rare cases it may well be just what the user intended.
In general, jumping based on user location may be more instructive than jumping based on browser language, but the former is still error-prone.
There is a language selection drop-down menu at the top of Dyson.be's pages On the first visit to Dyson.com, visitors are prompted at the top of the site page to select a preferred region and language. Users can click to cancel this prompt field, and later find the language picklist in the footer.
Backcountry automatically redirects users to another page Backcountry, an American outdoor gear and apparel company, automatically redirects its users to another page because as of 2018, to avoid violating GDPR regulations, the site is no longer available outside the United States to those users who cannot access the site without a VPN to buy and deliver gifts for friends in the United States.
Audi auto-jump based on user location Audi will automatically redirect the user to a page that it thinks corresponds best to the country. However, users can select their country and region by clicking on the language picklist in the upper right corner, and when they do so a text box with autocomplete will appear, as well as a 'Continue' button that is temporarily unclickable.
BMW avoids automatic jumps and guides users to make the right choice for them Global Edition BMW website does not automatically redirect the user to any web pages. Users can find the option "BMW in your country" in the top right corner of the page. Clicking on it will open a pop-up box listing all the options and the "BMW in your country" button will become visible above, clicking on it will redirect the user to the regional site considered to be the most suitable.
IKEA's language picklist has smart auto-complete IKEA There is no auto-jump. But there is a very prominent picklist that includes domains, endonyms (internal names), and languages for every major country in the world. Its 'Go shopping' button is probably the largest in the world, so large that it probably deserves to be in the Guinness Book of World Records. On the IKEA website, though, you can set the country and region, but not necessarily the language.
While polite jumping is reasonable, automatic jumping doesn't quite make sense. Bouncing users from one site to another without asking is actually planting assumptions in our design that are usually undesirable, and it's no wonder that some users get confused and even abandon using your product. Ironically, few people bother to track this part of the data, because the abandonment of use happens on 'another' site, and that site is usually managed by another department or team on the other side of the world.
Whether we want to direct users to another site, or just have to use auto-jump, it's best to allow users to override auto-jump** with manual settings. This requires us to tame our assumptions and decouple the relevant presets.
Unbinding between location and language presets
Many sites have an assumption that location, language and currency are usually tightly bound, e.g. if a user's location selects Germany, they may prefer to browse German and expect prices to be marked in Euros. However, this assumption works for some people, but for others it can completely ruin their experience of using the product.
Delivery location and language selection are tightly bound on Adidas and it is not possible to adjust the country region and preferred language separately For example, if you want to buy sneakers in Germany from the Adidas official website and give it to your friend in Poland, you have to make sure that you can read Polish at the checkout. You can choose to browse and deliver to Germany in German, or you can choose to browse and deliver to Poland in Polish, but you cannot choose to browse the site in English in the option to deliver to Poland. In other words, the relationship between language and location is tied up to death.
It turns out that this assumption does not work in many cases, such as.
- A person is using a German VPN but he is not in Germany and does not speak German.
- A person visits the site from Germany, but may only go to Germany for a few days, and Ta may not speak or understand German at all.
- A person lives in Germany and visits a website in German, but prefers to pay in dollars with a company credit card rather than in euros.
- A person living in Germany might want to send an item from an American store to an American friend, but keeps getting redirected to the German version of the site.
- A person visits the site from the US, but Ta needs to be able to provide a VAT number at checkout because the person responsible for purchasing the product is a German office and pays with a German credit card as well.
Of course, we might consider all of these situations to be very rare edge cases and choose to ignore them. But first, we need to keep track of how many people actually encounter such problems and end up abandoning your product as a result. In practice, and especially for global brands, these numbers may be larger than you think.
The reason for these problems is that we have framed common situations in tightly bound, even inflexible presets. Sure, presets have their uses as default options, but when the default presets aren't good enough, the situation gets out of hand. Unbinding presets from each other and letting users make their choices separately is actually a good idea.
Mondraker users can select location and language separately on Mondraker, users can select the location and language separately. All countries are divided into tabs, and the user can select the language they would like to use at the bottom. The disadvantage of this approach is that selecting a language based on the selected country may not be as efficient as selecting the language first and then the country.
Monese separates the choice of language and country with two tabs Monese shows Two tabs in the top right corner of the page header. Users can switch between language and country/region, defining their respective preferences separately.
User preferences do not have to be limited to just country/region and language. We can also allow users to customize other elements of the user interface, such as currency, automatic translation, units of measure, date formats, etc.
Allow users to set custom preferences
For many websites, language and location are only the first layer of important attributes that convey the match between the site and the user. However, in order to provide value to the user, we may have to think one step further.
Revolve can make separate selections for language, country/region, and currency Revolve.com will use the preset language, country/region and currency settings based on the user's IP and browser's regional settings **. However users can override these presets with custom preferences. They can choose the delivery country/region, the language displayed on the site, and the currency. The preference prompt is located at the top of the page and consists of a combination of language code abbreviations, flags and currency codes.
These details are sufficient to show the final price of all products, including the delivery costs to the respective region and the amount most familiar to the user. It enables a perfect unbundling of the location, language and currency in which it is located.
The choice of language and country/region is separate on Airbnb Airbnb Suggested languages are paired with the corresponding region shown, but also allow users to adjust their preferences and select their preferred language and region. In addition, users can choose to have the listing descriptions and reviews automatically translated into any language of their choice that is supported by Airbnb. This pop-up box appears when you click on the Earth icon in the top right corner of the header.
Once set up, users can switch between different travel destinations compare rates in the same currency and reviews are automatically translated into the language they are familiar with. This brings great convenience to the user.
iHerb provides a large number of additional preferences for users to choose from iHerb then goes a step further and provides users with a whole set of additional preferences. Not only can users choose their language, preferred currency and delivery destination (for US destinations this can also be specified by zip code), but they can also choose preferred unit of measure, check available payment methods and available delivery providers. Instead of the old-fashioned drop-down menu, these options also feature a menu that can be intelligently and automatically filled in.
On State Street Global Investment Management's website, users can define some specific preferences. The first time a user visits the site a pop-up box appears that explains to the user some of the site's assumptions about the user's location and the purpose of their visit. In this pop-up box, the user can change their location, specify their identity, and select their preferred type of website to visit.
In general, by selecting these options, the user takes the initiative and thus customizes the experience of visiting the site by themselves, e.g.
- distribution location
- monetary unit
- unit of measure
- Time/date format
- Time zone preference
- Level of own experience
The question, of course, is how to show all these settings to the user**. Is it a separate settings page, with a sidebar? Put it at the top of the page or in the footer? One option, actually, is to display these settings via a modal or non-modal pop-up box when the user enters the site - though this option is still controversial.
Example of a non-modal pop-up box
Product Localization Blue Book Note: A modal pop-up box is a dialog box that appears on top of the main content and puts the system into a special mode that requires user interaction. User interaction with the main content is temporarily closed by this dialog box and is not restored until after the user has explicitly interacted with the modal dialog box.
Admittedly, the modal pop-up box is actually not quite a good idea; it breaks the user flow and requires immediate action from the user, so it tends to get annoying. However, it's still appropriate to use it when we need to alert users to important details - such as missing data, mutually exclusive settings, critical errors.
Some of the sites listed above pop up a modal pop-up box** on a user's first visit, asking them to specify their intentions and preferences before using the site. On other sites, the default preset is applied silently, and the user has the option to adjust it if needed - sometimes using a pop-up box, sometimes requiring a trip to a dedicated page.
Peloton offers country/region preference options via modal popup boxes when users enter the site Although modal popup boxes are always noticed by users, the usability tests show that they are often instinctively ignored and sometimes clicked off before the user even realizes that the pop-up box says something. On the other hand, because users are so focused on the product, they also tend not to notice information like currency options, units of measure, or delivery locations on the navigation bar. Only when the language has to be changed are they likely to notice other setting items that can be adjusted.
Booking's language menu is a modal pop-up box
Booking's currency picklist, with the most common currencies listed at the top Booking Instead of using a tabbed model, it uses separate buttons for currency and language at the top of the page. It will infer some settings based on user device information and apply them directly, or the user can reselect them and override the preset options. It doesn't use a `` dropdown menu - it's usually the slowest form component, and all options are displayed as plain text so they can be searched via the in-browser search function.
By contrast, Skyscanner allows the user to tap a large button to bring up all the customizable options, and divides the options into several drop-down menus. Also, the interface always automatically reverts back to English if the user accidentally makes a wrong selection.
Which option is better? Ultimately, of course, usability testing will have to decide. In the particular case of the language picklist, showing the modal popup box when the user enters may not be a bad idea, as it provides actual value to the user - a value they may not find on their own. However, perhaps another alternative works better - using a non-modal dialog instead.
When entering the Patagonia website A fixed non-modal pop-up box will pop up in the bottom left corner. Users can select a location and language and save their preferences in a cookie. Users can also open the language picklist at any time by visiting the preferences bar in the footer.
In the mockup above, the important content is not blocked by the modal pop-up box** and the user can scroll, navigate, select and copy and paste. However, the preference pane appears in the lower right of the screen and can be collapsed or minimized, but it does require user action. This is more intrusive than silently placing it in the global navigation bar, but it's also easier to spot.
If you're not sure of the best option for your project, consider adding a link to the navigation bar first. Test out design-related key metrics to see how the results change with less intrusive and more friendly non-modal popup boxes versus modal popup boxes. The modal popboxes will likely perform better than expected.
Uses a clickable floating menu
Large businesses understand one thing very well: navigating through dozens of regional options in a tiny floating layer, or even a larger pop-up box, is quite a chore and requires quite elaborate sliding pages to do. As a result, there are often sites that display all available options on different pages, divided by region, sometimes with banners to illustrate.
Revolut Displays all available options on a separate dedicated page. The countries are displayed in English, grouped by region and arranged alphabetically. However, this page shows not only the available regions, but also the regions that are not yet available. For this particular case, it might be a good idea to allow users to filter themselves, for example by hiding all unavailable regions, perhaps with a toggle button or tab above the list.
Logitech Most of the languages displayed on the website are in the corresponding local characters, for example, "Deutschland" for Germany and "China" for China. This allows even users who cannot read English to find the region or language of their choice. On the page, all regions (and available languages) are grouped by geography and displayed in columns across the screen to make it easy for users to find them.
Dell Instead of showing all regions on one long page, sub-tabs , grouped the regions by geography. It doesn't use flags, so it's a bit hard to find. Countries/regions and languages have also been combined so that the user doesn't have to slide the page too much when looking up.
Not all sites have tabs that look the same. Cisco uses a small floating layer with vertical tabs that looks very compact and the solution is very simple and straightforward. It's worth noting that the main drawback of tabs, is that content cannot be found by in-page search (at least for now). Users also always have to select a locale before they can further select a country/region.
Of course, another way to group countries is to use a vertical accordion menu. eDreams does just that. You may need more vertical space as a result, but all the options can be swept through at once from top to bottom.
The official website of Oracle has a slightly different country picklist: clickable floating menu, where all countries are grouped and arranged instead of showing a separate page. This is a very compact and straightforward solution.
If you need to display a large number of languages, try if you can group them and display them on a single page. If the page becomes too crowded as a result, consider grouping them into accordion menus or tabs - provided that they are designed in a simple and straightforward tab style, without weird text labels. Or a better option could be used: autocomplete suggestions for users that go straight to the target.
Show autocomplete recommendations
Getting the autocomplete right is not easy. If we are dealing with both countries/regions and languages, this solution is not so easy to implement. To make autocomplete work better, we need support for common abbreviations, local sayings, and abbreviations for all available options. Of course, our autocomplete proposal should show both country/region and language, and provide the option to select country/region or language separately. In addition, support for multiple 'major' languages (e.g. English, French, Spanish) may also want to be considered. Put it this way, an autocomplete solution isn't easy at all!
on Framework locale/edit, the user can select country/region and language separately, both with autocomplete, the most commonly used option is highlighted and the user does not have to scroll through the list of countries/regions to find it. Although this may be perfectly adequate in some cases, unless the user's country/region does not appear in the list. At such times, we can display the region closest to the location of the user's input option without leading the user to a dead end.
In the above mockup, clicking on "4 nearby locations" opens an accordion menu highlighting the closest locations to Lithuania. The formatting is done indented. This model may not work well when the user is trying to open a new bank account, but if the user is looking for a specific office location, this solution may be useful.
Wise also provides an autocomplete function for language settings. If the same language appears in more than one item, the autocomplete function will specify which country it refers to. All language options are presented in their native text.
Porsche uses the accordion menu floating layer as well as the auto completion function. The interface supports abbreviations and shows the available options with flag icons.
It goes without saying that the autocomplete feature is a great addition to the language picklist. When testing, however, we want to look at how people use the autocomplete feature and what text they actually enter to find their country. Sometimes, fine tuning to make autocomplete work for different languages can be a notoriously difficult and overly time-consuming task.
Grouping of countries/areas for display
Not every location or language has to be represented by a separate entry in the language picklist. If multiple countries speak the same language, can the countries be displayed in groups by language?
Daniel Marchini came up with an interesting concept of displaying country flags by language in a language picklist. If multiple countries use the exact same language, is it really necessary to display them in separate entries? For example, the option Portuguese corresponds to the countries Portugal and Brazil, and Spanish corresponds to Mexico and Spain. Obviously, not all countries can be grouped this way, but if you're targeting users from a specific country, this option might be worth a try.
The country pick list for Airwallex groups all European countries under the "EU" option. Its service applies to the entire EU, so there is no need to select individual countries. However, if the picklist is slightly longer and you are looking for the option to open a bank account in the Netherlands, you may not realise until later that the Netherlands is assumed to be a country within the EU.
Use flags to indicate countries and text labels to indicate languages
When designing a country/region picklist, it's almost a natural choice to consider using flags from various countries - after all, flags are obviously an instantly recognisable option for users compared to mere text. This is indeed true, however as James Offer says in his article on Flags don't represent languages, flags are unique to each country/region, but languages tend to cross borders.
There are French speakers in Canada, Vietnam, Senegal, Switzerland and many other countries, and it would certainly be inaccurate to assume that all users from these countries associate their language of choice with the French flag.
In my thoughts on language selectors, Zsolt Szilvai shows an interesting example of this dilemma. During usability testing of an application designed for the UAE, many people found that Arabic was represented by the flag of a particular country. However, since Arabic is used in many countries, it cannot be represented by the flag of any one country.
Curve.com sets up a default international version of the English page, plus a few other options, but one might want to know the difference between 'International (English)' and 'English (US)'. Things get a bit confusing when using flags to indicate language.
Backmarket A row of flags has been placed in the footer to indicate the various local versions of the site. When we want to direct users to a specific local version of the site, it's safest to use the flags to represent the country, but not to indicate the language. Many sites will add a link to the local version of the site directly in the footer so that it can be easily found using a browser page search as well.
Use flags for countries/regions and plain text for languages. Bol.com seems to get it all right. The country picklist (with the flag) is in the top right corner of the page, and is where most users are used to going to find it.
To avoid misunderstandings, if your users need to select a specific country, be sure to use a flag. However, if you are offering your users the option of a particular language, using a flag may not work well, rather use the autocomplete feature to list all available countries and put a language text label next to it.
This leads to the next question: how exactly should these labels be written? Should they be written in English or locally in one language?
Use the native writing of the language as a text tag
Assumptions are easy to make, and this is true for combinations of currency, language, and location, as well as for tagging languages with text tags. We shouldn't assume that the language the user speaks is the language we choose as the default option. Instead, when a user selects a language, it is usually best to tag it using the native writing style for that language.
So instead of having options that assume the user can read English and write German and Chinese, you could mark those options as Deutsch and Chinese.
Every language on Stripe is written in native style, no flags are used however, if the language options are marked in native style, then foreigners who happen to be in foreigners who happen to be in China may have problems switching to their native language. Of course, using a flag would help people find the language menu button, but we could also modify the language menu button with a label, for example by prefixing it with the 'Language' label to make it easier to spot. We could also add a link labeled "English" at the top of the page. Of course, these are also assumptions on our part, but it would probably be easier than jumping around in both the navigation bar and the page source code.
Booking Use hover tips to tell users can change to another language on the local version page. If you choose to use a hover prompt (which is less common), consider using a language in the hover text that many users will understand, such as English.
Using Earth Icons and Translation Icons
Since using flags can go wrong, what would be a reasonable alternative to flags? As mentioned briefly at the beginning of the article, we can also use icons that indicate 'Earth' or 'Translation' for the region and language picklist. There is also an official language icon that is free to use, but unfortunately it is still not as easily recognizable as the others.
Language menu button with icons. Icon 1 shows the Earth, icon 2 shows two characters with different letters. Designed by Zsolt Szilvai Of course, not everyone will understand an icon combined with a word they can barely read, but if it is prominently placed at the top of the page or in the footer, the chances of being spotted by people are greatly increased.
Tomorrow.one displays a large drop-down picklist with an Earth icon in the footer of each page. There is no such menu at the top of its page. This may not be a big problem if the page is not very long, but if the user has to scroll a long time to get to the footer, or if the page's infinite scrolling prevents people from scroll to the footer, they may give up on that effort.
on the Atlassian, the language picklist is hidden in the footer at the very end of the page, indicated by a globe icon. However, if the user opens the site with another browser language setting, it will suggest language change at the top of the page, and a globe icon will appear there as well.
Monday.com places the The language picklist is placed at the top of the page in the upper left corner. All options are presented in three columns, with the current selection highlighted in blue.
While the banner is easier to identify, the icon can also be used as an alternative option, especially if you need to let the user choose the language rather than the location. Even if a picklist is provided at the top of the page, putting it at the bottom at the same time is a safe option, which ensures that users can easily find it when they need it.
Avoid using language abbreviations or acronyms
Zsolt Szilvai in testing another interesting issue found, related to using abbreviations, initials or codes to indicate languages. When there is not enough space in the navigation bar, we can use 'EN' for English, 'DE' for German and 'UA' for Ukrainian. In fact, these abbreviations are usually well understood, but they can bring surprising results when the user translates the site using the browser's automatic translation.
Quite surprising language options on Decathlon Mobile (pictured right) Not only does automatic translation often make menus explode frames and break layouts, it also translates language shorthand, producing an interface that can be very difficult to understand. However, by avoiding the use of abbreviations and instead using the full name of the language written in the local script, users don't have to deal with these issues at all. Having a translator translate the text manually would also make it easier for people to find their native language version of the page.
N26.de Use the abbreviation "EN" for English. The selected language is not clickable in the options list, but it might be better to boost the color contrast a bit. The header is still fixed at the top when the user scrolls down the page, so there's really no need to show the language picklist in the footer as well.
Wise Use abbreviations in the upper right corner to mark the language picklist, but when clicked will display the full name of the language** and uses a distinct focus style to show where the user is currently located. This avoids the problem of automatic translation, which often turns abbreviations into random strings.
Concluding remarks
Country and language picklists may seem like a fairly trivial design challenge, but there are a lot of little details that make or break the experience. When designing a picklist, be sure to ditch the presets and try to have as few ideas as possible where you can put certain options together. Users want the language selection unit at the top of each page or in the footer, and they often look for it via the flag, 'earth' or 'translate' icons.
If your product supports only a few languages, a drop-down floating layer may be perfectly adequate. If you need to display 10-15 languages, it might be worth trying a non-modal floating layer with autocomplete. If there are more options to display, consider using a separate page that organizes the countries/regions into tabs or accordion menus.
Language picklist design checklist
And finally or a checklist that includes some important principles to consider when designing a better language picklist.
- You can use page jumps, but avoid automatic jumps.
- Unbind between location, language, or other options.
- Allows users to set custom preferences (currency, time zone, units of measure).
- Consider using non-modal pop-up boxes.
- Show the country/region and language partition, or put it in the tab or accordion menu.
- Provides input boxes with autocomplete suggestions.
- You can use flags to represent countries, but don't use flags to represent language.
- Consider using the Earth and Translator icons and avoid using flags.
- Tag the language with the local script, e.g. Deutsch instead of German.
- Avoid using language codes or abbreviations.
- For accessibility reasons, country picklists are placed at the top and footer of the page and are available with keyboard shortcuts.