Stop Opening a New Translation Project for Every Release

Your app ships every two weeks. Some teams ship every day. The strings inside it change with every release, and so does the website copy and the help center behind it. Translation tools still think in projects, and a project has a start, a quote, an approval, a delivery, and an invoice. Content that never stops changing does not fit inside that shape.

So teams settle for one of two bad options. Either every release becomes a new project, and someone creates, quotes, approves, and closes dozens of tiny projects a quarter. Or releases pile up until there is enough to justify a project, and eight markets ship in English for two weeks. Continuous localization was supposed to end that trade-off. In most tools it only automated the paperwork.

Continuous projects in wxrks are built for that content. One project stays open for as long as the content lives. You re-import the file as often as you like, and only what changed becomes work. The step-by-step guide in our help center covers every setting. This post is about why it matters.

Why the Project Model Breaks for Software

The expensive part of a project per release is the paperwork around the words. Each project needs a name, a manager, languages, a memory, a glossary, a quote, an approval, a delivery, and an invoice. Multiply that by 26 releases a year, then by every product line, and the admin outweighs the translation.

It also breaks the question your stakeholders ask most. "Where are we on localization for the app?" When the answer is spread across forty projects named after version numbers, nobody can answer it in one screen. The honest answer is a day of digging, and the perception that follows is that localization is slow.

And it hides a quiet double charge. A string changes in release 12, changes again in release 13, and nobody translated it in between. In a project-per-release world, you were quoted for it twice.

One Project, Re-imported Every Release

A continuous project starts the way any wxrks project starts. Same wizard, same organizational unit, and the same project manager, languages, translation memory, and glossary the unit already knows. An account admin or project manager switches on one toggle, gives the project a tag your pipeline will use to find it, and uploads the first version of the file.

From then on, every new version of that file is a re-import, not a new project. wxrks compares it with the last version and records what was added, what changed, and what was removed. Unchanged strings keep their translations, comments, and history. Changed strings keep the previous translation as a draft, so nothing is thrown away. A file with identical content is detected and skipped.

That record is the Import batches tab. One row per push. The file, its version, and three numbers. Five added, three changed, two removed. For most localization managers it is the first time "what did this release change?" has an answer that does not involve asking a developer.

Imports Never Spend Money. People Do.

This is the part that matters for governance. An import only updates content. It never creates tasks and it never creates cost. New and changed strings accumulate, visible in the import history and, on a strings project, per language on the project overview, until someone decides to commission the work.

That decision is one action, Create Tasks for Outstanding Work. It collects everything untranslated, prices it with a single analysis, and creates the tasks per file, per language, and per workflow step. Pricing happens per work cycle, not per project. Run a cycle every Friday, every sprint, or whenever the numbers justify it. A scheduled pipeline call can run it too.

A string that changed twice before anyone touched it is priced once, because the newer version replaces the pending work. Content that lands while a task is already in progress waits for the next cycle, so nobody ends up with two open tasks for the same work. The guide walks through how commissioning works in detail.

The Same wxrks Your Team Already Knows

A continuous project drops the wrapper and keeps the work. It has no project cost, no project due date, no approval, and no delivery. Those belonged to the project. Now they belong to each cycle and each task. The wizard, the workflows, the vendors, the editor, the tasks, and the payables all stay.

Translators get something better than the same. On a strings project, one editor session opens every string for a language across every file, and each segment carries its key. Search by key, or type a prefix like "checkout" to see only the checkout strings. A filter called Latest import only shows just what the last release touched. The translator works on the release, not on a list of files.

For the Pipeline, Two Calls

Developers never need to open wxrks. Authenticate, then push the file with one request on the project's tag, on every release. If nothing changed, the call does nothing. If something changed, wxrks records it and waits for the next cycle. Everything in the interface has an API equivalent, including creating the project itself. The endpoints are listed in the help center guide.

This is what continuous integration promised for code, applied to language. Integrate small changes often, so no change is ever big enough to hurt. Translation had no equivalent while the project was the unit of work.

Where to Start

If your app strings, website copy, or help center articles ship on a schedule, pick one file and start a continuous project with it. Choose Strings if the content is keyed, like a JSON or YAML catalog. Choose Files if people should open and translate files one at a time. Then import the next release and look at the three numbers.

This is the first version of continuous projects, and more is coming over the next months. Book a demo to see it running on your own files.