Hyvä provides pre-translated localisation modules as Composer packages, one per language, covering all Hyvä-specific strings. You install the Hyvä module, add the matching Magento core language pack, then set the locale on the store view. Right-to-left languages work with modest adjustments. The real cost of a multi-language build is not translation. It is the testing surface.
Merchants scoping international Magento builds tend to budget for words and underestimate combinations. A store with four languages and two currencies is not one storefront with a translation layer. It is a set of store views, each with its own content, its own layout consequences, and its own chance to break. Here is what the framework gives you and what you are still on the hook for.
What Hyvä gives you
Per Hyvä’s localisation documentation, Hyvä maintains localisation modules for many languages, distributed as Composer packages. Each contains complete translations of the Hyvä-specific strings in the theme.
The sequence is short:
- Install the Hyvä localisation module for the language via Composer.
- Run
setup:upgrade. - Install the corresponding Magento core language pack.
- Set the store view language under Stores, Configuration, General, Locale Options.
That handles framework strings. It does not handle your strings, and the distinction matters when scoping. Anything your team wrote in a custom template or component is yours to translate, and if you are using the Hyvä UI component library there is a separate step: Hyvä UI ships an i18n/en-US.csv in your Magento installation that lists the translatable text in the components, which is the right starting point for identifying what needs covering.
For content rather than interface strings, Hyvä Commerce 1.1.0 added translation support for CMS content, so a single page can carry different values per locale rather than being duplicated per store view.
Right-to-left, honestly
RTL is usually treated as a large unknown in scoping conversations, and Hyvä’s position is more reassuring than most.
Per the RTL documentation, enabling right-to-left support requires minimal modification. Hyvä generally works well with RTL languages, with the exception of static properties such as margins and text alignment, which need adjusting. The simplest approach is setting the dir attribute statically through XML in your theme’s default_head_blocks.xml.
The practical read: RTL is a bounded task rather than a rebuild, and the work is concentrated in wherever your team hardcoded directional values. That is another argument for using Tailwind’s logical properties rather than fixed left and right utilities when you know an RTL market is coming. Teams that used directional utilities everywhere pay for it here.
What the documentation does not solve for you is design review. Layouts that read correctly mirrored still need a native speaker to look at them, because plausible-looking RTL and correct RTL are different things.
Where the time actually goes
| Work item | Covered by Hyvä | Yours |
|---|---|---|
| Theme interface strings | Localisation module per language | Install and verify |
| Hyvä UI component strings | Starting CSV provided | Translate and maintain |
| Your custom components | Nothing | All of it |
| Product and category content | Nothing | Catalog translation per store view |
| CMS pages and blocks | Per-locale values in Hyvä Commerce | Writing the content |
| RTL layout | Works with small adjustments | Directional CSS, native review |
| Text expansion in layouts | Nothing | Design and QA |
| Testing across store views | Nothing | Multiplied by every combination |
Two rows deserve expanding.
Text expansion is the quiet layout killer. German commonly runs substantially longer than English for the same string, and a button or navigation item designed to the English length breaks. This is not a translation problem, it is a design constraint, and it is much cheaper to handle by designing flexible components than by patching each break after launch.
Testing multiplies. Four languages across two currencies across mobile and desktop is sixteen combinations before you have considered B2B account states or logged-in versus guest. Nobody tests all of them manually every release. The workable approach is to test one representative store view exhaustively and then run a much smaller smoke set across the rest, chosen to cover the specific things that vary: currency formatting, text length, direction, and any locale-specific payment or shipping method.
A phased launch that does not overwhelm QA
The failure pattern in international builds is launching every market at once, discovering a class of bug that affects all of them, and fixing it eight times under pressure. Sequencing avoids that.
Launch the hardest market second, not first or last. Your first market should be the one closest to your existing storefront, because it validates the plumbing with the fewest unknowns. Your second should be the one with the most divergence, whether that is RTL, a different tax model, or a language with severe text expansion. Finding structural problems on market two means you fix them once and apply the fix to everything after. Finding them on market six means you have built five storefronts on a flawed assumption.
Freeze the theme between market launches. Adding markets and changing components at the same time makes regressions impossible to attribute. If a layout breaks in the new market, you want to know whether it is the market or the change.
Keep a per-market checklist rather than a single sign-off. Currency formatting, date formatting, address format and validation, phone number handling, tax display inclusive or exclusive, payment methods, shipping methods, legal and returns content, and text overflow in navigation. Most of these are not frontend concerns, which is exactly why frontend-led launches miss them.
Decide who owns translation upkeep before launch. Translation is not a project, it is a maintenance commitment. Every new component and every content change creates untranslated strings. Without a named owner, sites drift into a state where the primary language is current and the others are eighteen months old, which is worse for trust than not offering the language.
Structuring it before you build
Three decisions made early prevent most of the expensive rework.
Decide what varies per store view and what does not. Catalog, pricing, content, payment methods, and shipping rules can each be shared or split. Every split is flexibility you may need and maintenance you definitely acquire. Teams tend to split more than they use.
Decide where translation lives. Interface strings in translation files, content in the CMS, and product data in the catalog is the conventional and correct split. What causes pain is customer-facing copy hardcoded in templates, because it is invisible to whoever manages translations and only surfaces when a market launches.
Decide how a new market gets added. If launching a fifth language means a developer sprint, the architecture is wrong. It should be configuration and content work. The test is simple: can someone add a market without opening a template?
The related structural question, whether to use store views within one instance or separate instances entirely, is a bigger architectural decision than the frontend, and it should be settled first. Our guide to headless Adobe Commerce architecture for multi-store US brands covers when a Hyvä frontend is sufficient and when the complexity justifies more.
Performance across markets
One thing worth checking that teams routinely miss: measure Core Web Vitals per store view, not sitewide.
Markets differ in device mix and network quality, and a storefront that passes comfortably for your domestic audience can fail for a market on slower connections. Because assessment happens on field data from real users, a market with genuinely different conditions produces genuinely different results from the same code. If you are launching internationally, the baseline you captured at home does not transfer, and we set out the measurement discipline in measuring a Hyvä migration properly.
There is a second reason to keep the measurement per market. A new store view often picks up market-specific third-party scripts, such as a local analytics tool, a regional consent manager, or a payment provider’s widget. Each is added by someone solving a legitimate local requirement, and none of them appear in your domestic performance data. A storefront can therefore be fast everywhere you look and slow in the one market nobody is monitoring, which is usually the market with the least traffic and the least scrutiny.
How Bemeir helps
Bemeir is a Brooklyn ecommerce agency and the USA’s first official Hyvä Gold Partner, working with US brands selling into multiple markets and with international merchants selling into the US.
Our Hyvä development services cover multi-store view theming, localisation setup, and RTL work, and our Magento and Adobe Commerce development practice covers the catalog, pricing, and tax structure underneath, which is usually the harder half. We also build on Shopify and Shopify Plus, Shopware, and BigCommerce, and the tax, payment, and shipping providers an international build depends on come from our technology partner ecosystem.
More about the team is on the about Bemeir page, or start a conversation from the Bemeir homepage.
Frequently asked questions
Does Hyvä support multiple languages out of the box?
Hyvä maintains localisation modules for many languages, distributed as Composer packages, each containing complete translations of the Hyvä-specific strings in the theme. You install the module, run setup:upgrade, add the matching Magento core language pack, and set the locale on the store view. That covers framework strings only. Anything your team wrote in custom templates or components is still yours to translate.
Does Hyvä work with right-to-left languages?
Yes, with modest adjustment. Hyvä’s documentation states that enabling RTL requires minimal modification and that the theme generally works well with RTL languages, apart from static properties like margins and text alignment which need adjusting. The recommended approach is setting the dir attribute statically via XML in your theme’s default_head_blocks.xml. Budget for design review by a native speaker as well as the CSS work.
How do I translate Hyvä UI components?
Hyvä UI ships an i18n/en-US.csv file inside your Magento installation containing the translatable text used across the components. Use it as the inventory of what needs translating, then supply your locale files against it. This is separate from the theme localisation modules, so a build using Hyvä UI has two translation surfaces rather than one.
Can CMS content be different per language in Hyvä?
Yes. Hyvä Commerce 1.1.0 introduced translation support for Hyvä CMS content, so a single page can hold different values per locale rather than needing a duplicate page for each store view. That matters for maintenance, because duplicated pages drift apart over time and the divergence is rarely noticed until a customer points it out.
What is the most underestimated cost in a multi-language Hyvä build?
Testing. Languages multiplied by currencies multiplied by device types produces more combinations than teams plan for, and text expansion in languages that run longer than English breaks layouts designed to English lengths. Translation itself is usually the predictable part. The combinatorial QA and the layout fixes are what overrun.
