You've created a Tilda website, added a catalog, and set up order processing. Now you need to launch English and German versions. It seems simple enough to just translate the text.
According to CSA Research, 76% of buyers prefer to buy in their native language, and 40% will not buy in another language at all. But adding a language version and making it functional are different tasks.
In practice, a multilingual store is more complex than a regular multilingual website. It includes a dynamic catalog, shopping cart, checkout, payment notifications, and error messages. Each of these elements requires separate attention. If something is missed, a buyer from Germany will see a catalog in German with a Russian-language cart.
What exactly needs to be translated in the store
A Tilda online store has several categories of content that behave differently. Static page text is the lesser part of the problem.
Static Content
Store description, company texts, delivery terms, static blocks on the main page. This is translated standardly, any proxy translator can handle it.
Product Catalog
Tilda loads product cards dynamically via JavaScript. Names, descriptions, characteristics, and prices are generated after the page loads. Most translators only see the HTML structure, not what is loaded afterwards.
Result: the product in the catalog is called "Leather wallet", but when you go to the product card, the name is in Russian. Or the entire catalog remains untranslated.
Cart and Checkout
Tilda Store is a separate module with its own logic. Cart, checkout page, shipping address fields, payment method selection, "Pay" button — all these are separate components. Most services do not translate them.
System Messages
“Item added to cart”, “insufficient stock”, error notifications – all this is generated dynamically. Often it remains in the language of the original site, even when everything else is translated.
Emails and Notifications
Order confirmation by email is a separate story. Tilda sends emails through its mechanism, and Multify does not affect this process. This is not a bug or a limitation of a specific service: emails live outside the proxy's area of responsibility.
Technically, this can be solved through external automation. Multify passes fields with language, country, and domain from which the application was sent in the form data. If you connect n8n, Make, or an analog, you can set up the logic: an application came from the German version – send an email using the German template. But this is a separate integration that needs to be configured independently.
Why Standard Solutions Fail
Weglot and Linguise translate static HTML. Dynamic content (catalog, cart, messages) they either do not see or translate unstably.
Specific problem: when a user adds an item to the cart, Tilda accesses its servers and receives data in real time. By this point, the translator on the client side has already finished processing the page. It does not see new data.
The solution is server-side translation. When all requests to Tilda pass through a proxy, each response (including catalog data and cart status) is translated on the server, and the browser receives the ready result. The user always sees translated content, regardless of how they ended up on the page.
Currencies: Three Approaches and Their Consequences
A multilingual store almost always requires multi-currency. For a German buyer, prices should be in euros, for a British buyer — in pounds. There are three approaches, and each has different consequences for SEO.
Conversion in JavaScript
The most common method: a script on the page takes the ruble price and recalculates it into the desired currency directly in the browser. The user sees euros, but the HTML still contains rubles.
This is bad for SEO. Googlebot scans the page and sees prices in rubles. If your site is for the German market, it records a discrepancy between what it indexes and what the user sees. This affects ranking for German queries.
Manually Maintaining Multiple Catalogs
A separate catalog with prices in euros for the German version. It works, but requires manual updates every time prices change. Acceptable for a small catalog, but not for 200+ products.
Server-Side Conversion
Prices are recalculated on the server, and the user receives a ready-made page with the desired currency. Googlebot sees exactly what a German buyer sees: prices in euros, correct SEO, and up-to-date data.
You can choose the source of exchange rates: live currency exchange rate for the ruble market, ECB for the European market, or a manually specified rate — if you don't want prices to change daily with the exchange rate.
SEO: What Needs to Be Configured for Each Language Version
A multilingual store without a proper SEO foundation will be invisible in search engines of target markets.
hreflang
Hreflang tags tell Google that you have multiple language versions of the same page. Without them, the search engine doesn't understand which version to show users from each country and may consider language versions as duplicate content.
For a store, this is especially important: every product, every category, and every checkout page must have a correct hreflang. Google's official documentation describes the implementation rules in detail.
Sitemap for Each Language
The sitemap must contain all language versions of all pages. 300 products and three languages means 900 pages in the sitemap, each with its language specified.
Meta Tags for Each Version
Title and description in search results should be in the user's language. A German buyer sees a German product description, a French buyer sees a French one.
URL Structure
There are 3 possible models:
- subdomains (de.yourshop.com) — the easiest way, suitable for most online stores
- folders (yourshop.com/de/)
- different domains (yourshop.com/yourshop.de/)
Localization: What Goes Beyond Translation
Technically, translation can be set up in a day. But for the store to work for buyers from a specific country, several additional things need to be considered.
Date and number formats. In Germany, the price is written as "19.99 €", in the USA - "$19.99". Thousands separator, currency symbol position, date format. Small details that are immediately noticeable to a local buyer.
Payment methods. A Russian buyer is used to YuKassa or SBP. A European expects Stripe, PayPal, or SEPA transfer. Showing all payment methods to all users makes no sense, it creates confusion. It is better to show only those that work in a specific region.
Delivery terms. Each market has its own terms, its own carriers, its own delivery cost. This is configured separately for different regions.
Legal requirements. For the European market, a cookie banner in accordance with GDPR, a privacy policy in the user's language, and sometimes mandatory seller information (Impressum for Germany) are required.