PrestaShop translations and international selling

What we would do

We would start with the existing shop: its PrestaShop release, theme, modules, integrations, catalogue data, target markets and the people who will maintain translations and prices. Keep working native language and currency controls unless a tested requirement needs something else. Agree which languages, currencies and delivery destinations you will support before changing localisation settings.

Make the configuration changes on a protected staging copy with the same relevant modules and theme. Isolate customer emails, live payments and fulfilment exports, then rehearse the complete journey with reviewed translations and representative data. Keep the previous settings and translation exports, agree a live switch window and record how to reverse the change. Move the approved changes to the current live shop; replacing its database with an older staging copy could lose orders received meanwhile.

For an agreed mixed configuration backlog, the PrestaShop Full-Day Store Setup Service can cover prioritised setup work; translation production and country-specific tax or legal review remain separate tasks.

Choose the setup your markets need

Multiple currencies alone do not require multistore. If markets need separate operational configurations, assess multistore and confirm which data remains shared.

Map the operational consequences with the multistore guide before choosing separate shops.

Add a language and audit copied content

On modern PrestaShop, use International > Localization to review localisation imports and the Languages tab. Review the selected import items before applying a country pack: taxes, states, currencies and units are separate changes. Import only what you intend to change.

Adding a language does not translate your catalogue. In PrestaShop 1.7.8 and 9, language creation populates missing _lang rows from each shop's default language. You can therefore see populated English content in a newly added German language. Copied wording is a translation task, not proof that the German version is ready.

1. Install the language or appropriate pack. Keep the customer-facing language disabled while preparing it.
2. Review ISO code, language_code, locale and date-format fields. These have different roles. Modern number/currency formatting uses locale rules; a date-format field does not set decimal separators.
3. Check right-to-left settings and the actual theme/module layouts when applicable. An RTL flag alone does not validate every component.
4. Associate the language with the intended shops in multistore.
5. Inventory copied or untranslated content and replace it with reviewed translations. Preserve required fields rather than deliberately leaving them blank.

PrestaShop 1.6 uses legacy Localization menus and translation mechanisms. Do not apply modern CLDR, Symfony-domain or selector-module instructions to it unchanged. On current releases, compare your environment with the official compatibility chart.

Your employees' back-office language is a separate profile setting. Enabling German for customers does not require the warehouse team to work in German.

Translate catalogue, policies, interface and email

Editors may provide one shared language selector, particularly for products, rather than a flag beside every field. Confirm the selected editing language before changing text.

Keep a translation register with the item or page, language, shop, reviewer and publication status. Include menu links, banners and content stored inside module configuration, which a catalogue export may miss. Agree a glossary for recurring product terms, then record how changed source text will reach the translator after launch. A completed translation can become outdated when an import changes specifications.

Prepare shipping, returns, privacy and terms, then main categories and important products. Translate attributes, technical specifications, sizes, materials and instructions as carefully as marketing copy. Test checkout validation messages, payment-module text and every active module. Send actual test messages for order, account and dispatch events in each language; check longer wording, links, encoding and mobile layout.

Machine translation can be a first draft. Review accuracy, terminology, measurements, brand voice and market-specific meaning before publication. Machine-translated pages can be indexed; review the published content for accuracy and usefulness. Prioritise human review where mistakes affect the purchase, use or contractual meaning.

Fix module or admin text that stays in English

1. Reproduce the exact string, page, shop and language. Check the employee language for admin text and the customer language for storefront text.
2. Select the correct module/theme and locale in International > Translations. A translation for another theme or domain will not necessarily apply.
3. Search the source for the exact wording and identify its translation call. Legacy Smarty calls such as {l s='Text' mod='modulename'} differ from modern domain calls such as {l s='Text' d='Modules.Modulename.Shop'}.
4. For legacy modules, check modules/modulename/translations/xx.php and active-theme module translation overrides. The module's own file is not the only supported source.
5. For modern domains, check XLIFF catalogues and database overrides. Export a working catalogue to preserve its domain filenames and identifiers instead of hand-inventing translation keys.
6. For hard-coded JavaScript, inspect the module's server-to-browser translation mechanism. Editing a PHP translation file does not change arbitrary English inside a static JavaScript file.
7. Clear relevant translation/Smarty caches and retest. Purge a CDN only if it caches the stale HTTP response. Compiled Smarty templates are server-side files, not objects held by the CDN.

English wording in an otherwise French back office can be a missing translation, wrong locale/domain, hard-coded text, a catalogue-loading problem or a defect. Do not diagnose every case as “not a bug”. A phrase missing from the translation editor can also have extraction or dynamic-string problems.

Give the developer the visible phrase, page URL, selected language, current shop and steps to reproduce it. Ask which catalogue or content field actually supplies it and how the fix survives the next module update. A screenshot alone cannot distinguish an untranslated setting value from a translatable template string.

Theme-specific overrides can take precedence over module wording. Back up/export your translations before theme changes or upgrades and check them afterwards. For child-theme domain filenames and lookup, see the child-theme translation chapter.

Set currency, conversion and local prices

Language and currency are independent. English with PLN and German with CHF are valid customer preferences. Add currencies under International > Localization > Currencies, using the real currency code and appropriate shop associations. Modern locale formatting supplies number patterns and symbols. PrestaShop 1.7.8 and 9 currency forms expose a Decimals setting for precision.

Rates are multipliers relative to the default currency. With EUR as the default and GBP at 0.85, a base 100 becomes 85 GBP before other price rules. The default rate is 1. Check the direction with one known product before enabling a currency.

Base product prices are interpreted in the shop's default currency. Changing that default is a migration task: do not expect the localization setting alone to reprice the catalogue. Plan conversion of product and combination prices, amount-based reductions, shipping tariffs, other stored monetary values and rates on staging. Preserve historic order currency information.

For a deliberate local amount, use the product's Pricing > Specific prices with the target currency and a fixed price. A currency-specific fixed price can replace automatic conversion for matching conditions. Check tax basis, combinations, quantity, groups, countries, dates and rule priority. Decimal precision does not turn 47.83 PLN into a chosen 49.90 PLN price ending.

A fixed 42 GBP price instead of an automatically converted 41.73 GBP is a merchandising choice. It does not prove a conversion gain. Consider imports or a tested pricing tool when maintaining many currency-specific prices.

Maintain rates and test rounding

The Currencies screen provides a rate-update action. PrestaShop 9 also provides the protected admin cron_currency_rates.php endpoint, which calls the currency updater in each shop context. Follow the official rate-refresh instructions to build your installation's URL, keep its key private and schedule it with your server's scheduler. Do not publish a guessed token or admin path.

Monitor completion and resulting rates. Assign a named owner and a review schedule suited to your trading risk; record who responds when an update fails. A successful HTTP request alone does not prove that every currency changed. Check nonzero plausible values, supported feed currencies, the last successful run and converted test prices. A manual adjustment to an exchange rate can be overwritten by the next rate refresh. A currency-specific fixed price is not rewritten by the core rate updater; check separately whether catalogue imports or pricing tools overwrite it. Compare processor fees and settlement spreads separately.

Currency precision, global rounding mode and global round type are different settings. On modern PrestaShop, rounding mode and round type are under Shop Parameters > General (configuration keys PS_PRICE_ROUND_MODE and PS_ROUND_TYPE). Round type chooses item, line or total calculation. No choice guarantees that every sum of displayed rounded numbers equals the final amount.

Illustration at two-decimal rounding: a net unit price of 0.335 with 20% tax gives 0.402 gross. Three individually rounded gross units give 0.40 × 3 = 1.20. Rounding the unrounded gross line gives 1.206, or 1.21. Actual PrestaShop results also depend on configured computation precision, discounts and tax allocation. Test quantity, mixed tax rates, reductions and refunds on real invoices.

Choose the accounting behaviour appropriate to your business and confirm it with your accounting requirements. Do not treat one rounding mode as a universal tax-authority rule. Review any change on staging before it affects new orders.

Rehearse a currency rollout

Suppose your existing shop uses EUR and you want to offer GBP without changing the default currency. Use a known product and record its current tax basis, combinations and discounts so that a price-rule difference is not mistaken for a rate error.

1. On staging, add GBP in the intended shop context and verify the rate direction. Using the earlier illustrative rate of 0.85, a base price of 100 should convert to 85 GBP before other rules.
2. Choose whether that product will follow conversion or have a fixed GBP price. Check the result with a matching customer group, quantity, combination and delivery address.
3. Switch currency from the product page, add to the basket and continue through checkout. Compare products, discounts, shipping, tax and the final amount rather than checking only the header symbol.
4. Use the payment provider's supported test procedure, then inspect the order, invoice and provider record for the same amount and currency. If the payment option disappears, inspect currency restrictions and provider eligibility before changing prices.
5. Rehearse a supported refund and check its amount and currency in the shop and provider. Confirm the bank settlement and conversion arrangement separately with the provider.
6. Run the rate update and repeat the price checks. Confirm which products should move with the rate, which fixed prices should remain, and whether the next catalogue import preserves the intended rules.

Keep the expected results with the release checklist. A rate change, a module update or an import can then be checked against the same basket instead of relying on memory.

Make language and currency choices usable

Modern shops commonly use ps_languageselector and ps_currencyselector. Check their installed versions, activation, current-shop associations and theme placement. Classic commonly uses displayNav2; another theme may use a different hook or widget placement. PrestaShop 1.6 used blocklanguages and blockcurrencies with its legacy theme hooks.

If a selector is absent, confirm there are multiple active choices in the current shop, then check Design > Positions, template rendering and CSS. Do not assume the fix is a theme rewrite.

Keep controls discoverable on product, category, cart and other entry pages as well as the homepage. On mobile, show the current language and currency in a recognisable header control before the customer opens a menu. Use language names in their own language, such as Deutsch or Français. Flags represent countries, so they can be ambiguous. Text-only controls can be fully accessible; image controls need an accessible name. When text already names the language, a flag can be decorative. Verify keyboard operation, focus and mobile touch targets.

Show currency codes where symbols are ambiguous. Confirm the chosen currency persists across product, cart, checkout and the payment handoff. PrestaShop records order currency, but the payment integration must support it; bank settlement and conversion are determined by the provider and account. Place a test order, read the invoice and compare the gateway transaction and settlement.

Test a combined country selector before enabling it. It can suggest a matching language/currency but should permit mixed preferences. Keep explicit choices available when using browser-language or location suggestions. IP detection can be wrong for travellers and VPNs.

Keep the customer on the corresponding page

Open a translated product directly, change language and confirm that the selector leads to that product's translated URL rather than the homepage. Repeat on a category and a non-product page, then check that currency switching preserves the current page and basket. If a translation or destination is unavailable, define an honest fallback rather than sending every switch to an unrelated page.

If the native language control fails your presentation requirement, Language Switcher, Flag Selector offers same-page switching with language labels and flags; if you need a different currency control, Currency Selector uses the shop's currency mechanism while retaining the current page. Test either replacement in your theme and confirm that only the intended control is rendered.

For a mixed-preference test, choose German with CHF and a delivery country you actually serve. Changing the language must not silently choose a different currency or address. Changing the delivery address must apply the configured delivery and tax rules for that address, rather than infer them from German wording. Repeat as a returning customer to expose a saved preference that overrides the new choice.

PrestaShop 9's GeoIP configuration expects GeoLite2-City.mmdb under app/Resources/geoip/. Check the installed version's requirements, database access/licence and update procedure before enabling geolocation. Avoid forced redirects that hide language variants or override the customer's choice.

Publish usable language URLs and metadata

Review product/category names, descriptions, metadata and localised slugs in each language. CMS metadata belongs to cms_lang, while meta_lang describes registered pages/controllers. Write natural wording for the target market and keep internal links in the intended language.

Use separate, stable URLs for language versions. Native friendly URL routing can use language prefixes when multiple languages are active. Changing URL structure needs a tested redirect plan. Language-specific domains are not a simple per-language URL field in one shop; they require suitable multistore or custom routing.

Fully translated main content is not duplicate content merely because it is translated. Hreflang helps search engines identify equivalent language/region versions; it neither translates pages nor guarantees rankings. Each fully translated, indexable language page should name its own same-language URL as canonical; do not point every language's canonical at the source-language version, and verify reciprocal hreflang mappings between the canonical URLs. See the hreflang guide.

If the existing theme or SEO module leaves a confirmed mapping gap, Hreflang Tags Manager provides language mappings and an audit preview. Inspect the rendered page before and after activation so that competing generators do not publish contradictory sets.

Copied source-language content should stay on your translation inventory. Do not claim an inevitable SEO penalty or recommend blank required content as the alternative. Publish a language when it offers a coherent shopping journey, and include eligible URLs in your chosen sitemap implementation.

Check header, footer, CMS and promotional links after a language change; copied absolute URLs can still send customers back to the source language. Open a sample of old bookmarked URLs after any slug or prefix change and confirm that each redirect reaches the intended equivalent page without looping.

Complete the international launch checks

1. Check translations, copied fallback content, currency rates, fixed prices and number/date formatting in the intended shop.
2. Review measurement units, size conventions, technical wording and imagery for the audience.
3. Verify suitable payment services and supported order currencies.
4. Test delivery availability, destination taxes, import charges and the stated delivery/return conditions. Obtain route-specific tax advice where needed rather than deriving tax from language.
5. Test a whole order in each language/currency combination you offer, including confirmation, shipping email, invoice and refunds.
6. Check mobile/RTL layouts, long text, selectors, canonical URLs, hreflang and sitemap entries.
7. Enable the completed language and monitor missing strings, checkout failures and customer feedback. Recheck active modules after installs or updates.

What to ask your developer or agency

• Which shop, theme, module and integration versions were tested, and where are the results for each offered journey?
• Which translations, fixed prices and language URLs can the next import or update overwrite, and who maintains them?
• How will the approved changes reach the live shop without losing new orders, and what are the reversal steps?
• Who checks the first live orders and rate updates, and who handles a missing translation, failed payment or refund mismatch?

Approve the live switch only when the agreed journeys pass and their owners have the results. Record the configuration changes and keep backups before applying them. After activation, check the first affected orders and customer messages; if a route fails, pause that route while investigating and retain its order and payment records.

Questions owners ask

Can we launch a smaller translated range first?

Only if customers can complete the journeys you expose, including navigation, linked products, policies and checkout. Do not assume an enabled language hides untranslated products. Agree how unfinished content will be handled in your actual shop before publishing.

Can our translator work while the language stays disabled?

They can prepare editable content, but plan storefront review separately. Enable the language on the protected staging copy for layout and order tests before making it available on the live shop.

Will a new selector fix a payment method missing in GBP?

Check the payment module's currency restrictions, provider support and merchant account first. A selector cannot add a payment capability the integration does not support.

Should we disable or delete a currency we no longer offer?

Prefer disabling it for new purchases while preserving historic currency records. Check existing baskets, pending payments, refunds and accounting exports before changing availability.