Operations dashboard for localisation providers
An operations dashboard for localisation providers that shows open language issues per release, language and cause, revealing whether problems lie in the source, the translation or missing context.
What does this solution need to handle for localisation providers?
After a few releases, a localisation provider knows that some products cause more trouble than others, but not why. Are the issues down to strings without context, source text changing after freeze, one language where the translator keeps changing, or too little room in the interface? Reports are spread across review reports, screen tests, the portal and client emails after release. When a client asks at a review why one language keeps getting more issues, the answer is a hunch rather than an overview. A dashboard should show per release and language how many issues are open and where they come from.
From daily operations to working software.
Agree issue causes
First we set a fixed list of causes: missing context, source change after freeze, terminology error, translation error, text too long, variable or plural form wrong, and a problem in the software itself. Reviewers and screen testers use that list for every report, as does the project manager for client reports.
Connect reports from every step
The dashboard reads reports from string packages, review reports, screen tests and the portal. Per release and language a picture emerges of open and resolved issues with their cause. Because every report is tied to a string and version, you can see at which step the problem arose.
Investigate and discuss patterns
The overview shows which causes occur most per product and language. If missing context dominates, that is a point to raise with the client. If it is a translation error in one language, it is an internal matter. The project manager can click through from each issue to the string and the report.
Connect with what you already use.
Localisation providers have reports scattered across their translation environment, review documents, the portal and the mailbox. The dashboard brings them together without double entry, as long as reports in the string package or portal are logged with a cause. Clients sometimes keep their own tracker of language bugs after release; it can be imported if they provide an export. You own the quality data and decide what is shared with the client.
Internal view or shared with client
An internal view can be candid about your own translation errors. Sharing with the client works well for causes on their side, such as missing context or late source changes. Two views on the same data allow a conversation about improvement without blame, because every cause has a clear owner.
Look per language or per cause
A per language view shows where most issues sit but not why. A per cause view shows which problem is structural but hides that one language stands out. Both are needed; a review usually starts from the cause and zooms in on the languages where it occurs most.
Open issues only or resolved too
Open issues tell you what must happen now for the release. Resolved issues show how the process works: how many your own review caught and how many the client only found after release. That ratio is often the best quality signal, which is why the dashboard shows both.
What this looks like in practice.
Duehello
Invoices sent. Follow-up taken care of.
Read the story
Hotel Aadam Wilhelmina
Online check-in, even at two in the morning.
Read the story
BillingFlow
From invoice to payment. One clear flow.
Read the storyThe photos with the customer stories are illustrative, not photos of our clients.
Start with a scope you can verify.
A first version contains the fixed list of causes, combining reports from string packages, reviews and the portal, and an overview per release, language and cause. We test it with data from an ordinary completed release and with one where the client reports many issues in a single language after go live. Next come a view to share with the client and importing language bugs from their own tracker.
Explore our pricingHosting and careGood to know.
Explore pricing and optionsHow many releases before the dashboard means something?
After one release you already see per language which causes occurred. Patterns become reliable after several releases of the same product. The more consistently reviewers use the causes, the sooner the picture holds and the sooner you can discuss it with the client.
Can we see which issues the client causes?
Yes, through causes such as missing context or source change after freeze. These are not there to assign blame but to discuss with the client what could improve on their side, such as sending screenshots or guarding the freeze more closely.
How do we handle issues that are really software bugs?
They get their own cause, such as a string never made translatable or an interface that truncates text. They are passed to the client and do not count as language issues. The dashboard still shows how many there are, because they affect the language team's work.
Do reviewers have to fill in much extra?
No. With each report they pick a cause from the fixed list, which takes little extra time. Beyond that the dashboard only uses data already in the string package and the portal. If many reports come in as other, we adjust the list.
What often connects to this.
What would you improve first?
Select the issues that apply to you. Download your selection to prepare for a conversation. These choices stay in your browser.
Or discuss it directlyDiscuss operations dashboard for your business.
Describe what you want to build. You receive a proposal with goal, scope, timeline and a fixed price, so you know exactly what you are starting.
WhatsApp+31 6 13 62 49 11info@vorlyo.com Let clients book and pay for classes online, without phone calls or loose lists.
- Website with a live class schedule
- Online booking and payment
- Reminders by email and text
- Connection to the accounts