How to keep translations in sync with Revisionary in Strapi 5
Learn step‑by‑step how Revisionary helps you maintain consistent multilingual content in Strapi 5, from versioned content types to API queries and best‑practice workflows.
By the Revisionary team · · 4 min read
Strapi 5’s built‑in i18n features let you store content in multiple locales, but keeping those locales in lockstep during edits and publications can be tricky. Revisionary adds a full version history to each entry, and it also tracks translation changes per locale. This article shows how to configure Revisionary for multilingual projects, how to use its UI to stay aware of translation drift, and how to query the history from a Next.js front end.
1. Why translation drift matters
When editors update the English version of an article, the French, Spanish or German copies often lag behind. If the English draft is published while other locales are still in draft, end users may see inconsistent information. Revisionary solves this by recording every field change per locale and exposing a visual cue that tells you which locales are up‑to‑date.
2. Enable versioned content types for i18n
- Open Settings → Plugins → Revisionary → Content types.
- Tick the content types you want versioned (e.g.,
article,page). - Save the settings.
- Ensure the i18n plugin is installed and the locales you need are defined under Settings → Internationalization.
With both plugins active, every locale of a versioned entry receives its own version line in the Revisionary panel.
3. The Translations panel in the Content Manager
When you open an entry, the right‑hand column shows the Version history panel. Below it, the Translations sub‑panel displays:
- Locale status – a green check means the locale matches the latest version of the default locale; a yellow warning means the locale is behind; a red icon indicates the locale is in draft while the default is published.
- Changed fields – hovering a field shows a clock icon; clicking it reveals a timeline of edits for that field across locales.
4. Workflow to keep locales aligned
4.1 Draft‑first, publish‑later
- Edit the default locale (usually
en). - Save – Revisionary creates a new draft version.
- Switch to each target locale, copy or adapt the changed fields, and Save. The Translations panel will turn green once the locale version matches the default draft.
- When all locales are green, publish the default locale. Revisionary automatically publishes the matching versions of the other locales if they are in sync; otherwise, it warns you.
4.2 Using the Review space
If you need a separate reviewer for translations, enable the Review space (/docs/everyday-use/review). Assign the French copy to a reviewer; the reviewer can see the version differences and approve with a single click. Once approved, the Translations panel updates to green.
5. Restoring a translation without affecting other locales
Sometimes a translator makes a mistake that needs rolling back without losing updates in other languages.
- Open the Version history panel.
- Filter by locale using the dropdown at the top.
- Select the erroneous version and click Restore (or press
R). - Only the selected locale is reverted; other locales stay on their current versions.
- Optionally, add a milestone name like "Reverted French typo" for future reference.
6. Querying translation history from the front end
Revisionary extends the standard Content API with a history endpoint that can be filtered by locale.
// Example: fetch the last three versions of the French article
import fetch from 'node-fetch';
const slug = 'my-article';
const locale = 'fr';
const url = `${process.env.STRAPI_URL}/api/articles/${slug}?locale=${locale}&populate=history&limit=3`;
const response = await fetch(url, {
headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
});
const data = await response.json();
console.log(data.data.attributes.history);The history array contains objects with id, createdAt, updatedAt, and the changed fields. You can render a revision selector on your Next.js page that lets editors view past French versions side‑by‑side with the current English version.
7. Automating synchronization checks in CI/CD
Add a small script to your GitHub Actions workflow that fails the build if any locale is out of sync after a content deployment.
name: Check translation sync
on: [push]
jobs:
verify-sync:
runs-on: ubuntu-latest
steps:
- name: Install node
uses: actions/setup-node@v3
with:
node-version: '18'
- name: Run sync check
env:
STRAPI_URL: ${{ secrets.STRAPI_URL }}
STRAPI_TOKEN: ${{ secrets.STRAPI_TOKEN }}
run: |
node - <<'EOS'
const fetch = require('node-fetch');
const locales = ['en','fr','es','de'];
const slug = 'my-article';
async function check() {
const results = await Promise.all(locales.map(async locale => {
const res = await fetch(`${process.env.STRAPI_URL}/api/articles/${slug}?locale=${locale}`);
const json = await res.json();
return {locale, version: json.data.id};
}));
const base = results.find(r => r.locale === 'en').version;
const outOfSync = results.filter(r => r.version !== base && r.locale !== 'en');
if (outOfSync.length) {
console.error('Translations out of sync:', outOfSync.map(r=>r.locale).join(', '));
process.exit(1);
}
console.log('All translations in sync');
}
check();
EOSIf the script exits with code 1, the workflow fails, alerting the team to resolve the drift before release.
8. Common pitfalls and how to avoid them
| Pitfall | Why it happens | Fix |
|---|---|---|
| Publishing default locale while others are still drafts | Revisionary warns but you may ignore the UI cue. | Always check the Translations panel’s color indicators before publishing. |
| Over‑writing locale history with bulk imports | Bulk import APIs bypass the UI and may not create per‑locale versions. | Use the Document Service API with the locale parameter, or run a post‑import script that creates a revision entry for each locale. |
| Losing translation milestones after a restore | Restoring a version does not copy milestone names. | Re‑add the milestone after restore if you need it for tracking. |
9. Leveraging the Content API for audit purposes
The Audit log (/docs/everyday-use/audit) records every translation edit, including who made the change and from which IP address (anonymized if privacy is enabled). To export a CSV of translation activity:
const url = `${process.env.STRAPI_URL}/admin/audit-logs?entity=article&action=update&locale=fr`;
const logs = await fetch(url, { headers: { Authorization: `Bearer ${process.env.ADMIN_TOKEN}` } }).then(r=>r.json());
// Convert logs to CSV (omitted for brevity)Auditors can verify that every locale change passes through the Review space, satisfying compliance requirements.
10. Summary
Revisionary turns Strapi 5’s i18n system from a simple locale store into a fully version‑aware multilingual workflow. By enabling versioned content types, using the Translations panel, labeling milestones, and integrating the history endpoint into your front end or CI/CD pipeline, you can guarantee that every language version stays consistent and auditable.
For a deeper dive into Revisionary’s UI panels and permissions, see the official user guide pages linked throughout this article.
The Revisionary team
Developers who build Revisionary, a version history plugin for Strapi 5. We write about Strapi, web development, AI and application security.
This article was written with the help of AI.