How a multilingual project runs

1. First reply

You describe your site, its languages and what you need, through the contact form or by email. The first reply is free and carries no obligation. It says whether we think we could help. If what you need is translation rather than structure or design, the reply says so, because a translation agency would then be the better first contact.

2. Written quote

The quote states a fixed price in Swiss francs, the deliverables of each stage, what is excluded, and a timeline built around the dates you give us. VAT treatment is stated on it. Work starts once you accept it and pay the deposit described on the pricing page. Changes to scope later are agreed in writing, with their price, before the extra work begins.

3. Language map

Before any visual design, we agree a written language map:

• which languages the site offers, and the scope of each (full, task-based or summary);
• the address structure, such as language folders on your .ch domain;
• the page list for each language, and which pages are translations of each other;
• who writes, translates and approves each language;
• how the root address and missing translations are handled.

This map is the single record that the switcher, the hreflang annotations and the sitemaps are later built from. Google requires each language version to list every other one ¹, and generating that from one record is far more reliable than maintaining it by hand.

4. Design and build

Templates are designed and built in the source language, but reviewed with the longest likely text from the start. The W3C's guidance on translation notes that short strings grow the most ², so navigation, buttons and cards are tested with lengthened stand-in text before translations exist. If a right-to-left language is planned, both directions are tested as each template is made.

Language tags are set on every page and on passages in other languages, as WCAG 2.2 requires ³. Dates, numbers and prices are formatted from data with each page's locale tag.

At the end of this stage you review the site in the source language and approve it before translation begins. That approval is the content freeze: after it, the source changes only for logged corrections.

5. Translations

We send the agreed export to your translators, with a glossary template, screenshots for context and length limits for tight spaces. Your translators work on their own terms and deliver back in the agreed format.

We place every translation in the site and review each language in the real layout, on phones and desktops, looking for overflowing headings, cut-off buttons, links to the wrong language and untranslated messages. Your fluent reviewers then read each language on the pages and approve it. We do not approve language use ourselves.

6. Checks and handover

Before launch, every language goes through checks based on our locale QA checklist: language tags, switcher behaviour from deep pages, hreflang return links, canonical tags, sitemaps, formats, forms and confirmation emails. Languages that are not ready can stay hidden from the switcher, hreflang and the sitemap and launch later.

At handover you receive the site, the language map, a short guide for your editors on adding and updating translations, and the list of checks with their results. The balance of the quote is invoiced at this point.

After launch

Keeping languages current is part of running the site, and the language map says who owns each one. If you want help later, such as adding another language or reviewing the structure after a year, it is quoted as a new piece of work.

What we need from you along the way

• A named contact who can make decisions.
• Source-language content by the agreed date.
• Translators appointed before the content freeze.
• Fluent reviewers for each language.
• Timely approval at the end of stages 3, 4 and 5.

Delays on either side move the timeline; the quote explains how.