Business supplies and services: Digital job cards for localisation providers
Digital job cards for localisation providers: a string package with version reference that records translation, review and screen testing per language, so every delivery traces back to a release.
What a job card for localisation providers should hold.
At localisation providers, the overview gets lost between steps. A translator works on a file the client has since replaced. A reviewer changes a term, but the change never makes it back into the translation memory. A string that proved too long during screen testing is shortened in the delivery but not in the source package. Weeks later the client asks why a button is labelled differently in one language than in the previous version, and nobody knows at which step it changed. Every package therefore needs a version reference and a per language record of who did what.
Digital job cards for localisation providers
Example- 1
Create the package with a version
DoneOn arrival a string package is created with the client's version reference, the target languages and the context.
- 2
Sign off steps per language
In progressThe translator signs off their part, the reviewer sees which strings were changed and records their edits with a reason, such as terminology, tone or error.
- 3
Check and record the delivery
NextBefore delivery the project manager sees per language whether every step is complete and whether any reports are open.
From preparation to signed-off card.
Create the package with a version
On arrival a string package is created with the client's version reference, the target languages and the context. Each language gets its own line with the steps translation, review and screen testing. When a new version of the source strings arrives, the package is updated and it is clear which strings changed.
Sign off steps per language
The translator signs off their part, the reviewer sees which strings were changed and records their edits with a reason, such as terminology, tone or error. During screen testing, problems are reported per string with a screenshot: too long, wrong context or variable in the wrong place.
Check and record the delivery
Before delivery the project manager sees per language whether every step is complete and whether any reports are open. The package returns to the client with the version reference, and edits from review and screen testing are written back into the translation memory and glossary.
No more paper and loose photos.
Localisation providers usually run a translation environment with translation memory and a separate system or spreadsheet for project management. The string package links the two: the translation environment remains where translation happens, the package tracks status and version. The client owns the source strings and version references; you own the translation memory, terminology and the reports from review and screen testing.
Review everything or sample
Reviewing every string gives the most certainty but takes a lot of time on large releases. Sampling is faster but misses errors on rarely viewed screens. Many agencies fully review new and changed strings and only check earlier translations when they appear on a new screen. The package records which approach was chosen per release.
Screen testing by you or the client
Screen testing by your own reviewers catches issues before the client sees them but requires test environment access. If the client does it, reports arrive later and often less structured. The package can take reports from both sides, with their source noted, so nothing gets lost between the two.
Accept or defer changes after freeze
A change after freeze can go into the same delivery if time allows, or wait for the next release. Including it keeps the software consistent but puts pressure on review. Deferring is calmer but leaves an untranslated string for a while. The package shows which strings changed after freeze, so the decision can be made per string.
What goes on the job card.
String packages with a version reference, steps per language with sign off, findings from review and screen checks per string, and a check before delivery: we set that up for the team. Together we walk through an ordinary release, and a release where the client supplies a new version of the source strings halfway. Writing corrections back to the translation memory automatically and taking over task statuses from the translation environment can be switched on later.
View pricingSupport and updatesGood to know.
Explore pricing and optionsHow do translators know they are on the right version?
Every package has a version reference that is also visible in the translation environment. When a new version arrives, the translator is alerted and sees which strings changed. Work on the old version is not lost but compared against the new set.
Can we trace why a translation changed?
Yes. Every edit in review or screen testing is recorded with its reason and who made it. If the client later asks why a term differs from the previous release, you find the package and the report that led to the change.
What do we do with strings too long for the screen?
During screen testing the reviewer reports the string with a screenshot and a suggested shorter translation. If it cannot be shortened without losing meaning, it becomes a question for the client about more space or different wording in the source language.
Are review edits saved to the translation memory?
Yes, that is part of closing the package. Edits from review and screen testing are written back, so the next release starts from the improved translation. Terminology changes also go into that client's glossary for every later project.
What often connects to this.
- 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.
- Customer portal for localisation providersA customer portal for localisation providers where product teams view language reviews, check screenshots and answer string questions, organised per release and per language.
Job cards that come back complete.
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 Digital job cards for localisation providers: string package with version reference, translation, review and screen testing recorded per language.
- Create the package with a version
- Sign off steps per language
- Check and record the delivery