Currency selector and language flags: small details that make visitors stay

Reviewed June 2026, the ps_languageselector and ps_currencyselector modules and the displayNav2 hook described here apply to PrestaShop 1.7, 8 and 9.

A visitor from Spain lands on your German-language store. Within a couple of seconds they are scanning the top of the page for a way to switch to Spanish, or at least English. Find a clear selector immediately and they stay. Find nothing and they hit the back button, straight to Google to find a store that speaks their language. That snap decision happens on every international store, every day, and it is decided entirely by two tiny front-end widgets: the language switcher and the currency switcher.

This post is narrowly about those widgets. Where they live in a PrestaShop theme, which blocks and hooks render them, the flags-versus-text argument that genuinely affects conversion, and how to make both elements obvious without cluttering your header. It is the front-of-house layer. The plumbing behind it, adding the languages and currencies themselves, exchange rates, tax, and the hreflang that tells Google which version to serve. Each has its own home, and I will point you to those rather than repeat them here.

The two PrestaShop blocks that render the switchers

Before you argue about flags, know what you are actually editing. On a default PrestaShop 1.7, 8 or 9 theme, the header switchers are not hand-coded into your template. They are two native modules hooked into the top of the page:

• ps_languageselector, the language dropdown. By default it renders through the displayNav2 hook (the right side of the top bar) and exposes every language you have enabled under International → Localization → Languages.
• ps_currencyselector, the currency dropdown, also on displayNav2 by default, listing every currency enabled under International → Localization → Currencies.

So what does that mean for you? If a switcher is missing from your header, the fix is almost never theme surgery. Go to Design → Positions, find the displayNav2 hook (the default home of both switchers; some themes move them to displayNav1 or a custom top-bar hook), and confirm the module is transplanted there. If it is present but empty, the real problem is upstream. You have only one language or one currency enabled, so there is nothing to switch between. The widget correctly hides itself rather than show a pointless one-item dropdown.

One detail that trips people up: a switcher only appears once a second language or currency is active and assigned to the current shop (and, on multistore, to the current shop group). If you run several storefronts from one admin, check that the language is ticked for the right shop association, see PrestaShop Multistore: running multiple stores from one admin panel for how those associations work.

Where to place the selector

The language and currency selectors belong in the header, visible on every page without scrolling. PrestaShop's default top bar puts them top-right, and that is where international shoppers instinctively look. The two defensible positions are the top-right corner and a dedicated top bar above the main navigation. What matters is not which of the two you pick but that the widget is above the fold, recognizable, and present on the homepage, the page most first-time international visitors land on.

The failure mode is hiding it. Burying the switcher in the footer, or collapsing it inside a mobile hamburger menu with no visible flag or currency code, forces the exact two-second search that sends visitors back to Google. On mobile especially, keep at least the current language flag and currency code visible in the header bar, even if tapping it opens a fuller menu. A shopper should never have to hunt for proof that your store will speak to them in their language and price.

Flags vs text vs both, the argument worth having

This is the one genuinely contentious decision, and it has a correct answer for most stores. The trap is that flags represent countries, not languages:

• Flags only: visually fast to spot, but ambiguous and occasionally alienating. The German flag stands for Germany. Austrian and Swiss-German shoppers may not see themselves in it. A Union Jack for "English" quietly tells American, Australian, Indian and Irish visitors that the English here is for someone else. And if you sell into markets with political sensitivity around flags, a flag-only switcher can do real harm.
• Text only: precise and unambiguous, "English | Deutsch | Français | Español" can never be misread, but visually quiet. With six or more languages a text-only row gets cluttered and easy to skim past.
• Flags + text: the pragmatic choice most successful international stores land on. The flag gives instant visual recognition; the language name (written in its own language, Deutsch, not "German") removes the ambiguity. This is also the most accessible option, because the text label is readable by screen readers where a bare flag image is not.

PrestaShop's default ps_languageselector is text-based (it shows the language name). If you want flags or flag-plus-text, that is a template tweak inside the module's view or a switcher module that ships flag rendering, not a core change. If you do add flags, pick the flag of the country most associated with the language in your market, accept that it is a convention rather than a truth, and always pair it with the language name so the convention can't backfire.

The currency selector: showing a number people can read instantly

A price of "49.99 EUR" lands immediately for a Eurozone shopper. For a Polish visitor it triggers silent arithmetic from EUR to PLN; for a UK visitor, EUR to GBP. That mental conversion is friction, and friction sitting right next to the price is the worst place to have it. A currency switcher that lets the visitor see "229 PLN" or "£42" removes the math and lets them judge the price against their own internal reference instantly.

Two things make the currency selector pull its weight:

• Detect, then offer, don't force. The strongest experience is to show the store in a sensible default currency and language for the visitor, while keeping the switcher visible so anyone can override. Outright IP-based redirection backfires: VPN users land in the wrong place, expats want their home language not the local one, and search-engine crawlers can get bounced into the wrong version and mis-indexed. A gentle suggestion banner ("Browse in PLN?") beats a forced redirect every time.
• Consistency from product page to checkout. Showing EUR on the product page and only swapping to local currency at checkout ambushes the customer at the worst possible moment. Whatever currency the switcher selects must hold across the catalogue, cart and checkout, PrestaShop carries this through the customer's cart context, so the job is mostly making sure you haven't hard-coded a currency anywhere in the theme.

One honest boundary: the switcher changes the displayed currency. Whether you also charge in that currency depends on your payment gateway and your appetite for multi-currency accounting, a different decision entirely. The mechanics of adding currencies, ECB exchange-rate cron updates, per-currency rounding so "47.83 PLN" becomes "49.90 PLN", and charging versus merely displaying are all covered in Multi-Currency and International Selling on PrestaShop: a practical setup guide. If tax is also in play across the EU, Selling Across Europe from PrestaShop: languages, currencies and tax is the one to read.

Country selector: one choice instead of two

Some stores merge the two widgets into a single country selector: pick "Poland" and the store switches to Polish, to PLN, and to Poland's shipping options in one move. That is cleaner for the majority of visitors who genuinely want the matching set, and it removes a decision.

The cost is the mixed-preference shopper. An expat wants English language with PLN currency; a Swiss-German buyer wants German language with CHF. A combined selector can't express that. The rule of thumb:

PrestaShop ships the two switchers separately by default, so the combined-country pattern means either a dedicated module or front-end work. Decide based on who actually buys from you, not on which looks tidier in a mock-up.

The SEO trap hiding behind the switcher

A switcher is a UX element, but how you implement language switching has direct SEO consequences, and getting this wrong quietly costs you the international traffic the widget was meant to serve:

• Each language needs its own URL. PrestaShop does this correctly out of the box. Enabling friendly URLs gives you /en/, /de/, /fr/ prefixes (or per-shop domains on multistore). The cardinal sin is serving different languages on the same URL based on a cookie or IP guess; crawlers can only index one version of a URL, so your other languages effectively vanish from search.
• Self-referencing canonicals per version. Each language URL should point its canonical at itself, not across to another language, so you don't trip duplicate-content handling.
• Hreflang is the part the switcher can't do for you. The dropdown lets a human switch; hreflang tells Google which version to serve which searcher automatically. It is a separate, fiddly job with its own rules.

The hreflang mechanics. Return tags, x-default, language-region codes. Are involved enough to warrant their own read: Hreflang Tags: telling Google which language version to show. And if you are still building out the translated store itself, assigning translations, sorting URL structure and getting the catalogue genuinely multilingual rather than half-translated. Start at Multi-Language Store Setup: getting PrestaShop ready for international sales.

Clean, predictable multilingual URLs are also where a URL-management layer earns its keep, our SEO-friendly URL manager and the wider SEO configuration suite keep those per-language paths tidy and canonical so the front-end switcher and the search engines agree on what each page is.

The common mistakes, in one place

• Hiding the switcher. Footer placement or a flagless hamburger menu forces the two-second search that loses the visitor. Header, above the fold, visible on mobile.
• Flag-only switching. Ambiguous at best, alienating at worst. Pair every flag with the language name in its own language.
• Forced IP redirects. They break for VPN users, expats and crawlers. Detect and suggest; never imprison.
• Currency that changes only at checkout. Keep the selected currency consistent from product page through to payment. Surprises at checkout are abandonment triggers.
• Machine-translated content behind a real-looking switcher. Offering five languages where four are raw Google Translate erodes trust faster than offering one language well. Translate fewer languages properly rather than many badly.

Frequently asked questions

My language switcher isn't showing in the header, what's wrong?

Two likely causes. If the header is empty where the switcher should be, check Design → Positions and confirm ps_languageselector is hooked into displayNav2 (some themes move it to displayNav1 or a custom top-bar hook). If the module is present but renders nothing, the real problem is upstream. You have only one language enabled, so there's nothing to switch between, and the widget correctly hides itself rather than show a pointless one-item dropdown. On multistore, also confirm the second language is assigned to the current shop.

Should I use flags, text, or both for the language switcher?

Flags-plus-text for most stores. Flags represent countries, not languages, a German flag alienates Austrian and Swiss-German shoppers, and a Union Jack tells American or Irish visitors the English here isn't for them. Text alone ("Deutsch | Français") is unambiguous but visually quiet and clutters with six-plus languages. The pairing gives instant visual recognition plus the unambiguous language name written in its own language (Deutsch, not "German"), and it's the most accessible option because screen readers can read the text label.

Should I auto-redirect visitors to their language by IP?

No, detect and suggest, never force. Outright IP redirection backfires: VPN users land in the wrong place, expats want their home language not the local one, and crawlers get bounced into the wrong version and mis-indexed. Show a sensible default while keeping the switcher visible, and use a gentle banner ("Browse in PLN?") rather than a forced redirect.

Should I combine language and currency into one country selector?

Only if most of your visitors genuinely want the matching set. A combined "pick Poland → Polish + PLN" selector is cleaner and removes a decision, but it can't express mixed preferences, an expat wanting English with PLN, or a Swiss-German buyer wanting German with CHF. If you have a significant cross-border or expat audience, keep the two switchers separate so those combinations can exist. PrestaShop ships them separately by default, so the combined pattern means a dedicated module or front-end work.

Does the currency switcher actually charge in that currency, or just display it?

By default it changes the displayed currency, and PrestaShop carries that choice consistently from product page through cart to checkout via the customer's cart context. Whether you also charge in that currency depends on your payment gateway and your appetite for multi-currency accounting, a separate decision covered in the multi-currency setup guide.

Related reading

• Multi-Currency and International Selling, adding currencies, exchange-rate cron, rounding, and charge-vs-display.
• Hreflang Tags. The SEO half the switcher can't do: telling Google which version to serve which searcher.
• Multi-Language Store Setup, getting the translated store genuinely multilingual behind the switcher.

These two widgets are small, but the message they send isn't: a clear language switcher and a sensible local price tell an international visitor "we expected you, we're ready for you, you belong here." Get the placement, the flag-plus-text labelling, and the cross-page currency consistency right, and you have removed the friction that decides that two-second stay-or-leave moment. Which is the entire job of a front end built to sell across borders.