Catalan and Dutch for a Lovable Site: Script or Dedicated URLs?

For a small Lovable site, the simplest option is a script that adds a translated layer in minutes. Weglot's Lovable integration installs with a single script and no design changes, but a script alone may not create a separate address for each language or the hreflang tags that link them. If search visibility in Catalan and Dutch matters, look at in-app routes or a tool that adds real language URLs, and first check which framework your Lovable project uses.

Key takeaways:

• A script such as Weglot's installs in under 10 minutes, and adding it through the Lovable chat costs one Lovable credit.
• Lovable's own guide says hreflang tags are only generated with subdomain or subdirectory integration, not with JavaScript-only setups.
• Lantis charges €3 per month for one language and €2.50 per language per month for 2 to 9 languages, providing each language with its own URL.
• Lovable Pro starts at $25 per month according to Totalum, and Checkthat.ai adds that the domain itself is paid separately.

What is the difference between a translation script and real language URLs?

"Translate my Lovable site" can mean two different things. A script shows visitors translated text on top of the existing pages. Real language URLs give each language its own address, such as /ca/ and /nl/, so search engines can crawl each version and connect them to one another.

Weglot says that without language-specific URLs, its lightweight JavaScript integration still displays translated versions instantly, without changing the URL structure. That is the appeal: fast setup and nothing to change in the code. The limit comes from Lovable's guide, which is published by the platform itself:

"Hreflang tags are only generated with subdomain or subdirectory integration, not JavaScript-only setups." — Lovable, comparison guide

This matters because of what Google asks for. As summarised by Commoninja, Google requires a unique URL for each language version of a page, linked via hreflang annotations. Commoninja also notes that Google determines a page's language based on visible content rather than the lang attribute or the URL. Regardless of the route chosen, the translated content must be actual, readable text on the page.

The in-app route builds the language structure into the project. Commoninja describes it as adding an internationalisation library, creating one file per language and putting the language in the URL instead of a cookie, so each language has its own address. Lovable's multilingual guide says Agent Mode can manage multiple language versions, routing logic and hreflang setup. It recommends subdirectories as the best balance of SEO benefits and manageable complexity for most businesses.

Lovable's built-in generation of interface text has its own limit. Lovalingo, which sells a Lovable add-on, says Lovable can generate interface text in other languages but that this does not replace a full localization layer.

Whether or not to translate the URL slug itself (e.g., /contact vs. a Catalan or Dutch equivalent) is a separate decision, which we cover in Lantis's guide to translating URL slugs. Titles and meta descriptions are worth translating too, as explained in this guide to on-page multilingual SEO.

For a site with a handful of pages, the choice comes down to one question. Do you need separate indexable pages per language now, or is a visible translated layer enough while you test demand for Catalan and Dutch?

Which stack does your Lovable project use?

Lovalingo's instructions differ depending on whether a Lovable project uses TanStack Start or is a legacy React/Vite app. The same logic applies to any code-level route: the files to edit, the place where routes live and the way a library is installed depend on the framework underneath.

Before picking a tool, ask the Lovable chat to identify the framework and router your project uses and make a note of it. Code-level tools (like Lovalingo, an i18n library, or Agent Mode) require this information. A script-based tool or one that operates externally is less sensitive to this, though it is still worth knowing.

If you never edit the code yourself, a code-level approach still requires someone to review the output: the routes, the language files, and the tags in the page source. That review is part of the cost of the in-app route, even when the tool itself is free. A checklist for checking multilingual SEO can help with that review.

How do the options compare for a small site?

Five criteria apply to every option:

• URLs and hreflang: whether each language has its own address and hreflang annotations.
• Effort for a non-developer: what a non-technical person needs to do.
• Languages: which languages the option covers, and whether Catalan and Dutch are confirmed.
• Starting cost: the price to begin, not the full cost over time.
• Maintenance: what changes after launch, such as corrections or new content.

Weglot is the quickest to try. It says the integration installs in under 10 minutes with a single script and no design changes. The script goes in through the Lovable chat, which costs one Lovable credit, or on a paid Lovable account through the code settings. Its FAQ says some dynamic sections may not translate right away and can be added through an HTML block in its dashboard. Language-specific URLs are the thing to confirm on Weglot's side for your setup, since Lovable's guide ties hreflang to subdomain or subdirectory integration.

Agent Mode and an i18n library belong to the in-app route. Both put routing in the project, and Lovable's guide recommends subdirectories, so Catalan and Dutch would live under paths like /ca/ and /nl/. The effort is higher: someone has to prompt, review the generated routes and keep one file per language up to date. The translations themselves come from wherever you source them, so language coverage depends on that source.

Lovalingo and the Globalize.now skill sit between the two. Lovalingo says its setup adds automatic UI translation, locale URLs, html[lang], canonical and hreflang tags, with instructions that depend on the stack. Globalize.now's lovable-i18n skill installs Lingui in the code, and the company says the skill is free and does not use credits. Globalize.now also argues that runtime auto-translate tools can provide a quick demo but often causes layout shifts, which is why the code-based route is preferred.

Lantis provides each language with its own URL, automatic hreflang tags and sitemaps, and installs with a single line of code. It uses Gemini for translations by default, with Claude, DeepL, or DeepSeek as alternatives. Each language includes 500,000 words, with additional 500,000-word blocks available for a one-time fee of €1. There is no lock-in period, and all payments are fully refundable within 14 days. Limitations: it operates as a monthly subscription per active language, so verify that Catalan and Dutch are included in its list of over 60 supported languages before purchasing. Catalan plus Dutch costs €5 per month based on the 2-to-9-language rate. For details on the translation engine, see Lantis's article on DeepL for website translation.

Which option is the simplest for Catalan and Dutch?

The answer depends on what each language version needs to accomplish.

• Test demand quickly: use a script. Weglot is the example with the fastest documented setup. Lovable's comparison guide, written by the Lovable team, recommends Weglot or Wix if you need to quickly add translated content to an existing site. The trade-off is that JavaScript-only setups lack hreflang support.
• Have each language found in Google: Choose a path that creates real URLs. That means Agent Mode, an i18n library inside the app, or a tool that adds the URLs, such as Lovalingo or Lantis.
• Keep everything in the codebase: the i18n library or the Globalize.now Lingui skill give full control and need someone comfortable maintaining language files.

Next steps

• Ask the Lovable chat which framework and router your project uses, and note the answer.
• Decide whether you need indexable pages for each language now or just a translated layer to test demand.
• Confirm that Catalan and Dutch are in the language list of any tool before paying.
• After launch, check the page source for language URLs and hreflang tags using a multilingual SEO checklist.
• If you prefer a tool that adds a separate URL per language, Lantis is one option to evaluate alongside the others.

Frequently Asked Questions

Is a script enough to make my Lovable site multilingual?

If you only need to show visitors translated text, Lovable's guide suggests hreflang tags are only generated with subdomain or subdirectory integration, not JavaScript-only setups, so a script alone may not help each language rank.

Does Google need a separate URL for each language?

According to Commoninja's summary According to Google's guidelines, Google requires a unique URL for each language version of a page, linked via hreflang annotations.

Can Lovable translate the site by itself?

Lovable's guide says Agent Mode can manage multiple language versions, routing logic and hreflang setup. Lovalingo, which sells an add-on, says generated interface text does not replace a full localization layer.

Which subdomain or folder structure is recommended?

Lovable's guide recommends subdirectories as the best balance of SEO benefits and manageable complexity for most businesses, so Catalan and Dutch would sit under paths such as /ca/ and /nl/.

Sources

• Lovable: 8 Best Multilingual Website Builders Compared
• Lovable: How to Build a Multilingual Website
• Weglot: Translate your Lovable website
• Weglot: Available languages
• Commoninja: How to Translate a Lovable Website
• Lovalingo: Lovable i18n
• Globalize.now: Lovable i18n & localization
• Globalize.now: Make your Lovable app multilingual
• Totalum: Lovable Pricing 2026
• Checkthat.ai: Lovable Pricing 2026