Translating Forms on Tilda: Why It's Harder Than It Seems
In this article: why forms on Tilda are not translated by standard tools, what exactly breaks with Weglot and Linguise, how forms are structured in Zero Block, why the text after submission remains in the original language, and how all this is solved at the server level. Plus a checklist for verification before handing over the site to the client.
The client asks for a multilingual Tilda website. You connect the translation, check the pages — everything looks good.
But then you open the feedback form: field names are in Russian, the button says “Отправить” (Send), the error message says “Заполните поле” (Fill in the field). All this against the background of an English page.
This is how most Tilda translation solutions work. And it's not a bug of a specific service, but an architectural problem.
Why Forms on Tilda Are Translated Differently
Normal text on a Tilda page is static. It is embedded in HTML, and the translator can find it, replace it, and deliver it to the user. Everything is predictable.
With forms, the story is different. Tilda generates them via JavaScript: after the page loads, a script dynamically creates fields, field names, hints inside fields, and buttons. By the time the translator tries to find the text, it's not yet on the page. Or it's already there, but immediately replaced by Tilda's scripts.
This is called dynamic content, and it is this that breaks most translation solutions. Google officially recognizes, that JavaScript rendering creates problems even for indexing, browser translators face the same limitations.
Google officially recognizes, that JavaScript rendering creates problems even for indexing, browser translators face the same limitations.
In addition to field names, a form contains several categories of elements:
error messages upon submission ("Enter a valid email", "Field is required")
text after submission, "Thank you, we will contact you"
hints inside fields before filling
checkbox labels, including consent to data processing
submit button
Each of these elements requires separate processing, and each has its own technical characteristics.
A Special Case: Forms in Zero Block
Tilda allows you to create forms in two ways: through standard blocks and through Zero Block (a visual builder with complete layout freedom). Technically, these are different implementations, and their logic of operation differs.
In practice, this means that if translation works for standard forms, it does not guarantee correct operation for forms in Zero Block. Some elements may not be translated or translated unpredictably. This is not an exception, but a consequence of how Tilda is structured: the same functionality is implemented in several independent ways.
What Exactly Breaks for Competitors
Weglot
Weglot is focused on translating static HTML content of a page. Since Tilda forms are created dynamically via JavaScript, their content does not always fall within the processing area, which can cause forms to remain in the original language.
You can try to bypass this using Weglot's "visual editor" — manually add form elements for translation. This works partially: you can translate the main fields, but error messages and text after submission will still remain untranslated. Plus, every change to the form on Tilda needs to be re-entered manually in Weglot.
Linguise
Linguise uses an additional layer on the browser side. It works better with dynamic content but remains dependent on how forms load in Tilda. As a result, the translation may be unstable: on some pages, forms are displayed correctly, on others — partially or with omissions, depending on the block configuration.
Custom Solutions
Some agencies solve the problem manually: they duplicate the page for each language, creating separate forms with translated fields. This is a reliable approach, but it requires maintaining multiple copies of forms and synchronizing them with every change, which increases labor costs.
How Form Translation Works in Multify
Multify works as a reverse proxy between the user and the site: the request passes through Multify's servers, where the content is translated on the server, and the user's browser receives the ready result.
Instead of catching dynamically created elements on the page, Multify intercepts Tilda's responses and translates the content on the server. The user receives already translated HTML, and Tilda scripts display the form in the correct language.
All form elements are translated:
field names
hints inside fields before filling
submit button
error messages during submission
text after submission
checkbox labels
At the same time, Tilda form logic is not broken: integrations with amoCRM, Bitrix24, or any other CRM continue to work. Data is sent as usual.
A separate story: consent to data processing
There is one form element that requires special attention: the checkbox for consent to personal data processing.
On a Russian-language website, it usually refers to the "Privacy Policy" with text according to 152-FZ. On a German website or a website for a European audience, this is already GDPR, and the legal requirements for wording are different: consent must be explicit, separate for each purpose, without pre-filled checkboxes.
This is not just text translation. This is localization of legal content — replacing one legal context with another.
Multify translates the checkbox text as regular content. But the correct legal wording for a specific market should be prepared by the team. This is beyond the scope of automatic translation.
Practical advice: if you are launching a website for a European audience, prepare a separate consent text for the language version and provide it as a “manual translation” — most serious tools support overriding individual strings.
Text after form submission
Another point where everything breaks: the message the user sees after clicking the button.
Technically, it appears not as static text, but as the result of an event after a successful response from the server. Many translators miss this state: the page is translated, but "Thank you for your application, we will call you back within 30 minutes" remains in Russian.
For a user who filled out the form in English, this looks like a failure, especially if they don't read Russian.
In Multify, the text after submission is translated along with the rest of the form content, because the translation applies to all page states, not just the initial load.
By the way, in an online store on Tilda, checkout is also a form submission. The same fields, the same error messages, the same confirmation text. All the same translation problems, only the price of the error is higher.
Why does Weglot translate the entire website but not Tilda forms?
Weglot works with HTML that is already on the page at the time of loading. Tilda forms are created dynamically via scripts — their content does not yet exist when Weglot scans the page. Therefore, it simply doesn't see them.
If I duplicate the page for each language, will the forms be translated?
Yes, this works. You create a separate page with a form in each language and switch users between them. The downside is that any change to the form requires manually updating all copies. For two languages, this is tolerable; for five, it's already a serious maintenance problem.
Is data from the form transmitted correctly after translation?
Yes. Translation only affects the displayed text: field names, hints, buttons. The data that the user enters into the fields is transmitted as is — name, email, phone are sent to CRM without changes. Integrations with amoCRM, Bitrix24, Google Sheets continue to work.
Can I manually set the text for a specific form element?
Yes. In Multify, you can manually set the translation for any string. This is especially useful for legal texts: consents, policies, disclaimers, where automatic translation may not take into account the local legal context.
Conclusion
Translating forms on Tilda is not a matter of “selecting a language in the settings.” It is a separate task with several levels of complexity: dynamic element creation, error states, legal content, and different implementations of the same functionality.
Most tools solve it partially or not at all. If form translation is critical for your project, check this first before connecting and configuring everything else.
See how your website looks in another language
Leave a link — we'll show you a demo right on your website.