A Continuous project is built for content that never stops changing — app strings, website copy, help center articles, anything that lives in a repository and gets pushed on every release. Instead of creating a new project for every release cycle, you keep one project open indefinitely and re-import files as they change; only what actually changed becomes new work.
​

💡 Who is this for? This guide is for Account Admins and Project Managers who need to set up, manage, and integrate with a Continuous project within the wxrks platform.

A few terms come up throughout this article:

1. Go to Projects → New Project and fill in the wizard as usual.
2. In step 1 (Configuration), turn on the Continuous project toggle — visible only to Account Admins and Project Managers — then pick Files or Strings (see "Strings projects" below) and confirm the CI tag. wxrks suggests one from the Project Reference, but it must be unique within the Organizational Unit.
3. Upload files and finish the wizard as normal. The project is sealed as Continuous automatically at the end of creation and opens straight into the Continuous view: no cost or due-date widgets, an Import batches tab, and — for Strings projects — a Languages dashboard on the Overview tab.
4. If automatic sealing fails for any reason, the project stays a Draft with the Continuous intent saved. Open it and choose Seal as Continuous from the project actions menu instead.

Files and Strings are two modes of a Continuous project, not two different features. Choose Files when people should open and translate files individually, the same way a regular project works. Choose Strings when keyed content from several files (JSON, YAML, and similar catalogs) should behave like one searchable string list — see the dedicated section below.
​

You can undo a seal (Unseal — back to Draft, from the project actions menu) only while no import batch exists yet. Once the first re-import happens, the seal is permanent — from there, the only ways out are Cancel or Delete.

A Continuous project looks and behaves differently from a regular project in a few consistent ways:

1. Continuous badge and CI tag pill - the titlebar shows a Continuous status badge and a fixed CI tag pill next to it. The tag is part of the project's identity — it never appears among the project's regular editable tags, and it can't be removed from there. "Continuous" is also available as a filter in the main project list.
​
​

2. No project cost and no project due date. The cost, work-unit progress, and due-date widgets are hidden, and the Costs tab doesn't exist on a Continuous project. Pricing happens per work cycle instead of per project, and deadlines live on individual tasks rather than on the project itself.
​
​

3. Import batches tab - lists every re-import: which file, its version, how many strings were added, changed, and removed, its status, and the date. If an import fails, hover the status badge to see why.
​
​

4. Tasks are created per work cycle, sized to whatever is actually outstanding at the time. A work unit only ever has one open task at a time — content that arrives mid-task simply waits for the next cycle. Task due dates are calculated from that cycle's word count. The Work cycles tab lists every cut, with its status and task counts.
​
​

5. The Editor adapts too. Opening a task shows the file's full content, with filters to focus on the latest import or on untranslated strings only. Unchanged strings keep their existing translations, comments, and history; changed strings keep the previous translation as an unconfirmed draft instead of losing it; removed strings disappear from view. Uploading a file with identical content is detected and simply skipped — it doesn't create a new batch.

When creating a Continuous project, choose Strings instead of Files to manage content as a set of keyed strings — the right choice for apps and websites where many files converge into one list of strings to translate.

What's different in Strings mode:

Only key-stable formats are accepted: JSON, YAML, XML, XLIFF, properties, .xcstrings, .strings, RESX, PO, and ARB. A file with duplicate keys is rejected at import — keys must be unique within a file.
​
​

The Overview tab opens with a Languages table instead of the usual file list: each target language gets its own string counts (total, translated, new) and progress bar, plus two actions per language — Open all strings (the pencil icon) opens one merged editor session with every string of the project for that language, across every file; Download gets a zip of that language's translated files. Right after an upload, these actions stay disabled for a short while until wxrks finishes creating the underlying work units — that's expected, not an error.

Selecting Open all strings for a language skips file-by-file navigation entirely. The Editor joins every file for that locale into one session, keeps each string's key visible right beside its source text, and hides the file preview panel so there's more room for the actual segments. To focus on what's left to do, enable the Not confirmed filter in the Editor's filter panel.

Open Filters when you need to narrow down a large strings catalog. Choose the Key option next to Source/Target to search by key instead of by text (substring and regex modes both work), or enter a value in Key prefix (namespace) to keep only one namespace — for example checkout. to see only checkout-related strings. The namespace filter is debounced, so results refresh shortly after you stop typing.

A note for Vendors: if you're assigned a Strings task, everything above works the same way inside your normal Editor session — the key-aware search and filters are simply there whenever the project you're working on is in Strings mode.

This section is for whoever wires a CI/CD pipeline, a static-site build, or an app-string export step to push content into wxrks automatically. If you're only managing Continuous projects through the web app, you can skip this section.

Authentication: POST /api/v3/auth/login with a base64-encoded {"username":"...","password":"..."} body. The JWT is returned in the X-AUTH-TOKEN response header — send it back in that same header on every subsequent call.

A typical pipeline integration is just two calls: authenticate, then PUT …/file with the exported file on every release. If nothing changed, the call is a no-op; if something did change, the strings are recorded and wait for the next work cycle.

Projects created through the CI API are born sealed as Continuous by default for every Organizational Unit. Units that were already using the CI API before the sealed model existed keep their historical behavior instead (each re-import flows through a chain of draft projects) — they were switched to "legacy" automatically, so nothing changed for them unannounced.

The switch lives in Organizational Unit → Translation Settings → General → Continuous Projects → "Create continuous projects sealed", and requires Organizational Unit management permissions. Turning it off only affects newly created tags from that point on: existing draft chains keep working and drain naturally, and once a sealed project exists for a given tag, every future upload for that tag goes to it. The Continuous project toggle in the project creation wizard is not affected by this setting either way — it always creates a sealed project.

Uploads never create tasks by themselves — they only accumulate new and changed strings, visible on the strings dashboard and in the Import batches history. Work is commissioned by a work cycle: a Project Manager clicks Create Tasks for Outstanding Work (from the project actions menu, or from the strings dashboard on a Strings project) — also available as the work-cycles endpoint above for a scheduled call. That action prices everything outstanding with a single analysis and creates one task per file × language, per workflow step that actually has work.

Content that arrives while a task is already in progress simply waits for the next cycle — a work unit never has more than one open task at a time. When a task is delivered, the next workflow step (review, for example) is automatically commissioned for exactly the content that was just completed, and anything that piled up in the meantime is picked up along with it. Task payment is based on the analysis snapshot taken at the moment of the cut.

Two related behaviors worth knowing about: on autopilot projects, a translator with a qualifying quality record can skip the review step automatically — the content is confirmed directly and no review task is created. And an Organizational Unit that shouldn't generate translator payables at all (an internal team, or a flat-fee arrangement) can be set to the NONE settlement mode, where Continuous tasks are never priced and never appear in payables — this is a backend setting the wxrks team configures per Organizational Unit on request, not something you toggle yourself in Settings today.

Supported files. Structured, key-stable formats work best — JSON, YAML, properties, XLIFF, .xcstrings, RESX, PO. Spreadsheets work but are sensitive to row insertions (a row added in the wrong place can look like mass churn), and free-form documents like Word or IDML files aren't a good fit for continuous re-import.
​
​

String identity is the key. Renaming a key counts as removing one string and adding a different one — keep keys stable across releases if you want to preserve existing translations.
​
​

If the same string changes again before anyone translated the earlier version, the newer version simply replaces the pending work — you're never charged twice for a string that was superseded before it was worked on (final payment still follows your Organizational Unit's payable configuration).
​
​

Removed strings are kept internally for history and translation-memory purposes, but they no longer appear anywhere in the interface or in any counts.

"Open all strings" or "Download" is greyed out right after I upload files. This is expected — wxrks is still parsing the file and creating its work units. The row updates on its own once processing finishes; there's nothing to fix, just refresh the page after a moment.
​

I uploaded a file but no tasks showed up. That's by design — uploads only record what changed. Use Create Tasks for Outstanding Work (project actions menu, or the strings dashboard) to actually commission tasks for the accumulated changes.​
​

I can't unseal my project back to Draft. Unsealing only works while no import batch exists yet. Once the first re-import has happened, the seal is permanent — Cancel or Delete are the only remaining options.
​

My CI tag was rejected as already in use. CI tags must be unique within an Organizational Unit among live (non-deleted, non-cancelled) projects. Pick a different tag, or reuse the existing project instead of creating a new one.
​

Still stuck? Search the wxrks Community for similar questions, or reach out to [email protected].

Related articles: How to create a translation project in wxrks for the full standard project wizard walkthrough, Project Overview for a tab-by-tab reference of the regular project page, and All about Organizational Units for the full Translation Settings reference, including the sealed-by-default switch covered above.