Business supplies and services: Website for localisation providers
A website for localisation providers that explains how software, apps and help content are translated and tested per release, so a product team knows what to supply and when.
What visitors want to know from localisation providers.
A product team looking for a localisation provider often compares nothing but languages and word rates. What it does not ask: how do you handle strings with no context, variables in the middle of a sentence, or text that no longer fits a button in German? What happens when a developer changes a label after string freeze? Localisation providers that leave this unexplained receive enquiries with an export file and a deadline, and only discover after delivery that the client expected screen testing too. The site has to show that localisation is a process repeated every release, with a role for the product team, rather than a one-off translation of a file.
Website for localisation providers
Example- 1
Services by product type
DoneWe describe the services by kind of product: a web application with monthly releases, a mobile app with store listings, desktop software with a manual, or a help centre updated separately from the software.
- 2
Explain the release rhythm
In progressA dedicated page walks through a release: source strings arrive, the language team translates with context, reviewers check in the screens and the package goes back with a version reference.
- 3
Ask about their way of working
NextVisitors answer questions about their situation: what format are the strings in, is there a test environment or do screenshots come along, how often do they release? Those answers carry over to the enquiry form and give the account manager a picture of the workflow before the first call.
From first visit to enquiry.
Services by product type
We describe the services by kind of product: a web application with monthly releases, a mobile app with store listings, desktop software with a manual, or a help centre updated separately from the software. Each type states what gets translated, which checks are included and what the product team supplies.
Explain the release rhythm
A dedicated page walks through a release: source strings arrive, the language team translates with context, reviewers check in the screens and the package goes back with a version reference. It also covers what happens with changes after freeze. A product manager sees exactly where their own team fits into the process.
Ask about their way of working
Visitors answer questions about their situation: what format are the strings in, is there a test environment or do screenshots come along, how often do they release? Those answers carry over to the enquiry form and give the account manager a picture of the workflow before the first call.
Connected to your software.
Localisation providers often have a site with a language list, a few sector pages and a quote form that asks for a file. The new site keeps the language list as a managed list, so a new language or pair is added in one place and appears everywhere. Examples of localised screens are only shown with permission or using fictitious products. Enquiries arrive in the system where you create projects, along with the answers about release rhythm and file format.
Show a per word rate or not
A word rate is what buyers search for, but it says little about repetitions, matches from earlier work or testing in the screens. Quoting only a word rate invites comparison with vendors who provide no context or checking. Explaining how repetitions and previously translated strings count, and that testing is listed separately, gives a fairer picture.
Pages per language or per service
Language pages attract searchers who need a specific language, but often say the same thing with a different language name. Service pages explain the approach better. A language page only makes sense when there is something particular to say, such as script direction, long compounds or plural forms that affect the interface.
Technical or business explanation
Developers want to know which file formats and integrations work; product managers want to know how it affects release planning. One page trying to serve both becomes unreadable. Two entry points, one on the per release workflow and one with technical delivery details, get each reader where they need to go faster.
How it already runs at similar businesses.
IP Camera Installatie
From camera system to installation. Everything connected.
Read the storyMaison Vert
From bouquet to delivery. Thoughtfully connected.
Read the story
MJ Tattoo Studio
From inspiration to a personal consultation.
Read the storyWhat goes on the website.
We build service pages per product type, a page on release rhythm, the language list as a managed list and the questions about way of working, and put the site live. Beforehand we go through it as a visitor who wants to ship a web application in a handful of languages, and as a startup that only needs an app's store texts translated. Language pages where they add something real, a technical delivery page and an English version for international product teams can be added later.
View pricingHosting and careGood to know.
Explore pricing and optionsShould every language we offer get its own page?
Only when there is something specific to say per language, such as script direction, text length or plural rules that affect the interface. Otherwise the language list with a short note per language is enough. Pages that differ only in the language name do not help visitors and are a burden to maintain.
Can we show clients' localised screens?
Only with their permission, and often better not for software that has not launched. An alternative is a fictitious product showing how an overlong translation is resolved or how a variable shifts within a sentence. That explains the approach without exposing confidential screens.
How do we explain what string freeze means?
On the release rhythm page, with a simple timeline that avoids fixed durations: until freeze, source text may change; after it, the language team translates a stable set. Changes after freeze are still possible but run as a separate round. A product team then understands why late changes affect delivery.
What if a visitor does not know what format the strings are in?
They can leave that question open and attach a sample file. The account manager usually recognises the format from the file and contacts the developer if more is needed. The form only asks what a product manager can reasonably be expected to know.
What often connects to this.
- Enquiry form for localisation providersAn enquiry form for localisation providers that gathers source strings, screen context and release details, so the language team knows where every string appears before translation starts.
- Quotation software for localisation providersQuotation software for localisation providers that prices word volume, previously translated strings and testing per language separately, so a product team sees where release costs come from.
- Scheduling software for localisation providersScheduling software for localisation providers that aligns language teams, reviewers and each client's release window, so every language is ready when the software ships.
A website that explains your offering.
Start with a short intake. Then we schedule a call to show the software with your services, team and way of working.
WhatsAppinfo@vorlyo.com Website for localisation providers: localisation services, language packs and the per release approach explained clearly for product and engineering teams.
- Services by product type
- Explain the release rhythm
- Ask about their way of working