Intento Translation for Jira

Read any Jira issue in your own language. Intento Translation translates an issue's summary, description, and comments on demand — right inside the issue — using the Intento machine-translation platform.

Translation is view-only: the original issue is never changed and nothing is written back. Each person picks the language they want to read in; everyone else keeps seeing the original.

Translate an issue on demand

Open an issue and find the Translate (Intento) panel. Pick a target language — that's it, there's no separate "Translate" button. The summary, description, and every comment appear translated, while the issue's own fields stay exactly as they were.

Links, code, and formatting stay intact

Only the words are translated. Links keep working (a named link keeps its destination — just the visible text is translated), linked Jira issues still render as their live cards, and code — inline snippets and code blocks — is left untouched and rendered as code. Bold, lists, and other formatting carry over unchanged.

Compare original and translation

The Compare original & translation button opens a side-by-side view, one row per item — summary, description, and each comment — with the original on the left and the translation on the right, aligned so you can check any single piece at a glance. Each row keeps its links, cards, and code intact.

Any language you've configured

The language dropdown lists every language your team has made available. Switch between them and the issue re-translates instantly.

Keep the right things untranslated

Some text should never be translated. The app automatically protects and restores:

• Do-not-translate hashtags you define (for example #DNT), case-insensitive.

• Placeholders like {{count}}, %s, or ${value}.

• Web links, Jira issue keys, and translation keys.

• Code — inline code and code blocks are left in the original entirely.

Admins can add their own patterns. Everything else translates normally around these protected pieces.

Admin setup

A Jira admin connects Intento once for the whole site. Open ⚙ Settings → Apps → Manage your apps → Connected apps → Intento Translation → Configure and set the Intento API key, the languages people can translate into, do-not-translate rules, and whether users can report translation issues. The API key is stored securely and never shown again after saving.

For each setting, the admin also decides whether project admins are allowed to adjust it for their own project — the "Project admins may override" switch next to each one. The API key and connection hostname are always managed centrally and can't be delegated.

Per-project settings

Where the admin allows it, a project admin can tailor settings for their project without affecting anyone else — for example, offering a different set of languages, adding project-specific do-not-translate terms, or turning feedback reporting on or off. Anything left alone simply follows the site-wide setting.

A project that inherits everything from the site defaults:

A project that overrides a few settings:

An override takes effect immediately — for instance, a project that limits languages to English and Japanese shows only those in the translation dropdown:

If an admin later stops delegating a setting, any project value you'd saved isn't lost — it just stops applying, and comes back if delegation is turned on again. When a setting is centrally managed, the project page shows it as read-only, with a note explaining that your admin manages it and a button to remove your saved value if you no longer want it.

Report a translation issue

Spotted a bad translation? When reporting is enabled, every translated item — summary, description, each comment, and every row in Compare — has a small Report translation issue icon (a faint warning mark that turns red when you hover it).

Clicking one opens a short form for that specific item:

• the source text and the current translation, shown for context (read-only),

• a suggested translation, pre-filled with the current one so you can quickly correct it,

• an optional comment describing what's wrong.

Your report goes to Intento to help improve translation quality over time. No rating, issue category, or personal information is sent. If something goes wrong sending it, the form stays open with your text intact and a See more option that reveals the technical detail, so you can pass it to support.

Installation

Everything a Jira site admin needs to install the app, keep it up to date, and remove it cleanly. For what to configure once it is installed, see Configuration; for the permission and data-flow model, Security and data flow.

Before you start

This app is not "Runs on Atlassian". That badge is reserved for apps that keep all data inside Atlassian's infrastructure. This app translates by calling the Intento platform, so content leaves Atlassian by design. Security and data flow sets out exactly what is sent and what is not.

Install

The app is installed from its Atlassian Marketplace listing by a site admin, like any other Cloud app. During installation Atlassian shows a consent screen listing the permissions the app asks for and the external hosts it may contact — that screen is the complete, authoritative list. The scope table explains why each entry is there.

End users are never prompted. The admin consents once, on behalf of the site.

Nothing is translated until the connection is configured — go straight to Configuration after installing.

Where the app appears

Both issue surfaces are read-only views. The app never writes to an issue, so it changes nothing about your issue layouts, workflows, or notification behaviour.

Upgrades

Atlassian handles delivery, and how an update reaches you depends on what changed:

• Most updates arrive automatically. Fixes and new features that do not change the app's permissions are rolled out by Forge to every site with no admin action and no prompt. You cannot pin an older version.

• Updates that change permissions wait for you. If a release adds, swaps, or removes a permission scope, changes the external hosts the app contacts, or changes its content security policy, Atlassian treats it as a new major version and does not apply it until a site admin consents. Until then your site keeps running the version it has.

Release notes say explicitly when an entry requires consent — see Release notes, whose entries are headed by the same version number your administration screen shows, so you can find the one you are running. The version itself is assigned by Atlassian rather than chosen by us; the mechanics are documented under App versions.

Your settings survive upgrades. Nothing needs to be re-entered, including the API key.

Uninstall

Uninstalling from the site's app administration removes both issue surfaces, the admin page, and the project settings tab immediately. Users see the issue exactly as it always was — translation was only ever a view, so there is nothing left behind in your content: no fields, no properties, no comments, no attachments, and no change to any workflow.

What happens to the settings you saved. The app's stored configuration — the API key, languages, do-not-translate rules, delegation toggles, and every project-level override — lives in Atlassian's Forge storage, inside your site's Atlassian infrastructure. On uninstall Atlassian soft-deletes it and retains it for 28 days before permanent deletion, per its hosted-storage data lifecycle.

If you reinstall, the app starts empty — old settings are not restored automatically. Reconnecting a new installation to the previous data is possible only on request to Atlassian, with your consent, and only within 21 days of the uninstall. In practice: if you plan to reinstall, keep a note of your settings, and treat the API key as something you will paste again.

Nothing about uninstalling touches your Intento account or any translation history stored there — that is governed by your agreement with Intento.

Sandbox and multiple sites

App settings are stored per installation. A sandbox site, a second production site, and your main site each keep their own API key, languages, and overrides — configuring one does not configure the others. Expect to set up each site you install on.

Verifying it works

1. Open any issue you can already read.

2. Open the Translate (Intento) panel.

3. Pick a target language from the dropdown.

The summary, description, and comments appear translated, and the original issue is untouched. If you see "Translation not configured", the API key has not been saved yet; if you see an error, open See more on the message — it carries the detail support needs. Troubleshooting maps the common cases.

Configuration

The app needs an Intento connection before it can translate anything. Site-wide settings are configured once by a Jira admin; a subset can be delegated to project admins.

Installing the app: Installation. Permissions and data flow: Security and data flow.

Where the settings page is

App configuration lives in Atlassian administration, not in Jira's own settings menu.

Open ⚙ Settings → Apps → Manage your apps. Jira redirects to Administration → Connected apps → Installed apps (https://admin.atlassian.com/s/<cloudId>/user-connected-apps/tab/installed). Open Intento Translation there and use its actions (Configure / View app details).

The older Jira settings → Apps path (https://<your-site>.atlassian.net/jira/settings/apps) returns 404 and the app does not appear in that menu. If you followed an old bookmark or an out-of-date guide, that is why. (Verified on a live site, 2026-07.)

Bookmarkable deep link. The Configure action lands on a stable Jira-domain URL you can save or hand to automation:

https://<site>.atlassian.net/jira/settings/apps/configure/<appId>/<envId>/static/intento-admin/<envId>

Substitute your site, the app id, and the environment id — both ids are visible in the URL the Configure action opens.

Only a Jira admin can save on this page. The app checks the permission on the server, so a non-admin who reaches the page cannot save: the page answers "You must be a Jira admin to save these settings."

Site-wide settings

Defaults on a fresh install: hostname https://syncwrapper.inten.to, routing best, languages en, ja, fr, zh-Hans, zh-Hant, ko, do-not-translate #DNT, skip codeBlock, code, both toggles on.

Project-level overrides

A project admin can tailor a subset of the settings for their own project — a different language set, project-specific do-not-translate terms — without affecting any other project.

Open Project settings → Apps → Intento Translation. Saving requires the project's Administer projects permission, enforced on the server.

Each field shows the inherited site-wide value alongside it. An override replaces the site value for that field rather than merging with it; a field left alone simply inherits.

The API key and hostname are never delegable. They stay site-wide permanently, and no toggle exposes them to project admins. A shared key handed to project admins is a key that leaks; a per-project hostname without a per-project key is worse. This is settled, not a gap waiting to be filled.

Choosing what project admins may override

Next to each of the six delegable settings the site-wide page carries a "Project admins may override" toggle. Five default to on; default routing id defaults to off, so routing delegation is something you opt into deliberately.

Turning a toggle off makes that setting centrally managed: project admins see it read-only, and your site-wide value applies to every project.

Revoking keeps the data. Turning a toggle off does not erase project overrides. They are kept exactly as saved and simply stop applying. Turn the toggle back on and each project's override reactivates as it was — no project admin's work is silently destroyed.

The page tells you the blast radius before you save:

• Switching a field off shows "N project(s) currently override this field (KEYS…). Their overrides will stop applying but stay saved." A checkbox, "Also delete these project overrides" (unchecked by default), is the only way to actually erase them. If the count cannot be fetched the page falls back to a generic note — the count is informative, not a precondition.

• Switching a field back on shows the mirror warning: "N project(s) have saved overrides that will become active again (KEYS…)." — so re-enabling months later does not surprise you.

Enforcement is server-side, not hidden UI. A locked field resolves from the site-wide config everywhere it is used, including the language dropdown and the translation itself. A project admin working from a settings tab opened before you locked a field cannot sneak an override in: on save the server drops the now-locked fields, leaves their stored values untouched, saves the rest, and reports back — the project admin sees "Some fields are no longer overridable and were not saved: …". They can always remove their own stored override while a field is locked; they just cannot add or change one.

Reusable configuration across projects

The site-wide settings are the reusable configuration: every project inherits them unless its admin overrides a delegated field, and locking a field forces every project back onto the site-wide value. Setting up a new project takes no configuration at all.

Not available today: multiple named configuration templates that a system admin defines and assigns to projects in bulk. The model is one site-wide configuration plus per-project overrides. If you need several distinct profiles applied across many projects, that is a roadmap item, not a setting you are failing to find.

After saving

Reload an issue, open the Translate (Intento) panel, and pick a language. Links, Atlassian smart-link cards, and code survive translation intact, and Compare original & translation shows both side by side, one row per item.

If something fails, the error carries a See more disclosure with the error code, message, the response from Intento, the endpoint, and the routing used — everything support needs. Troubleshooting covers the cases you can fix yourself.

Security and data flow

What the app can read, whose permissions it uses, what leaves your Jira site, and where the Intento API key lives. Written for admins and security reviewers evaluating the app.

The short version

• The app is read-only. It cannot write to an issue, and does not ask for permission to.

• It reads Jira as the person using it — never with elevated rights.

• The text being translated leaves Atlassian and is sent to the Intento platform. That is the app's entire purpose, and it is why the app does not carry the "Runs on Atlassian" badge.

• The Intento API key is stored as an encrypted Forge secret and is never returned to the browser or shown to anyone after it is saved.

What the app can read

Atlassian shows this list on the consent screen at install. There are two scopes and no others:

There is no write scope. The app cannot create, edit, transition, or delete anything in Jira, cannot post comments, and cannot alter issue fields — not by configuration, but because the permission to do so was never requested.

Outbound hosts

Both are declared in the app and appear on the consent screen. The app contacts nothing else. Adding a host in a future release would change the app's permissions and therefore require a fresh admin consent before it reached your site.

Whose permissions apply

Every read of Jira content runs as the signed-in user, using Atlassian's own authorization. The practical consequence: a user can translate exactly what they can already open, and nothing more. Issue-level security, project permissions, and browse restrictions apply unchanged — the app has no path around them, because it never reads with its own identity.

There is no consent step for end users. The site admin consents once at install.

Who can change settings

Both checks run against Atlassian's permission API on every save. Hiding a form is not the control; rejecting the save is. A stale browser tab cannot be used to save a setting the user is no longer allowed to change.

What leaves your site

On a translation. The text of the item being translated — the issue summary, description, and comments — is sent to syncwrapper.inten.to together with the target language and the routing id. Formatting, links, and code are preserved locally: code is excluded from the request entirely, and link targets, mentions, and card references are not part of the translated text.

When "Use Intento translation cache & storage" is on (the default) the request also carries the issue URL (https://<your-site>.atlassian.net/browse/KEY-123) as the storage key, plus a checksum per text segment. This is what lets Intento reuse a previous translation instead of paying for it twice. Turning the setting off removes both from the request.

On a translation-issue report (only when reporting is left on, and only when a user clicks the control): the reported item's source text and its translation, the target language, the user's optional suggested correction and comment, the issue link, the routing used, and an identifier of the app version. No rating, no account data, no user identity, and no email address is sent.

What is never sent anywhere: attachments and image contents, issue fields other than the ones being translated, user accounts or profile data, and the contents of any issue nobody asked to translate. The app translates on demand, per user, per issue — there is no background job walking your site.

What the app stores

Inside Atlassian's Forge storage, on your site:

• the site-wide configuration and every project override;

• the Intento API key, written as an encrypted secret — a distinct storage class that the app writes but the front end can never read back. It is used only inside the app's server-side code to authenticate to Intento, and no screen, log line, or API response ever exposes it.

Translations are not stored by the app. There is no app-side translation cache and no copy of your issue content in app storage. Caching, where enabled, happens on the Intento side under your Intento agreement.

On uninstall this storage follows Atlassian's retention rules — see Installation.

Data residency and the Atlassian badge

Because translation requires calling Intento, content leaves Atlassian's infrastructure in the course of normal operation. This makes the app ineligible for the "Runs on Atlassian" badge, and that absence is expected rather than a finding. What happens to content once it reaches Intento — processing location, retention, sub-processors — is governed by your agreement with Intento, not by this app.

If your organisation restricts which apps may access which projects, those controls apply normally. A project the app is excluded from is simply not translatable.

Reporting a security issue

Contact Intento support with the details. Error messages in the app carry a See more disclosure containing the error code, the endpoint, and the response — useful to attach to a report, and safe to share: it never contains the API key.

Troubleshooting

Symptoms an admin or user can hit, what causes them, and what to do. Configuration reference: Configuration.

First: collect the detail

Every failure in the app shows a See more disclosure under the error message. Open it. It carries the error code, the message, the response Intento returned, the endpoint, and the routing id that was used — which is usually enough to identify the cause from the table below without any further digging. It never contains your API key, so it is safe to paste into a support ticket.

Nothing translates

Reporting a translation issue fails

Settings won't save

Surfaces missing

Translation looks wrong

Escalating

Include: what the user was doing, the issue key, the target language, and the full See more contents. If the failure is at save time rather than translate time, say which page — site-wide settings or project settings — and which account attempted it.

Release notes

Release notes for the Jira app.

Which number is this? The heading of each entry is the version Atlassian shows for the app — on its page in your site administration, and on its Marketplace listing. Atlassian assigns that number itself when the app is deployed, so it is the one you can actually see and quote; it advances when the app's permissions change rather than once per release, which is why the steps are uneven. (build is our own internal number, carried on translation reports for support.)

How updates reach you. Most releases are delivered by Atlassian to every site automatically. A release that changes the app's permissions is not applied until a site admin consents — entries below say so explicitly when that is the case.

3.7.0 — 2026-09-11 · build 3.24.0

First public release. What the app does at this version:

Translation

• Translate an issue's summary, description, and comments on demand, into any language the site has enabled, from the Translate (Intento) issue panel or the Translate sidebar glance.

• Translation is view-only. The original issue is never modified and nothing is written back; each reader sees their own translation.

• Compare original & translation shows both side by side, one row per item.

• Links, Atlassian smart-link cards, and code survive translation intact; code blocks and inline code are left untranslated by default.

• The detected source language is shown where the translation engine reports one.

Keeping content untranslated

• Do-not-translate hashtags, placeholders ({{count}}, %s, ${value}), URLs, Jira issue keys, and translation keys are protected automatically and restored afterwards.

• Admins can add their own protected patterns as regular expressions, validated on save.

Configuration

• Site-wide settings: Intento API key, hostname, routing, target languages, do-not-translate rules, translation-issue reporting, and Intento cache & storage.

• Project admins can override target languages, do-not-translate hashtags, skipped formatting types, reporting, cache & storage, and — where the site allows it — the routing.

• Per-field delegation control: a site admin decides which settings project admins may override. Revoking keeps stored overrides and deactivates them rather than deleting them, and re-enabling restores them exactly.

Translation feedback

• Readers can report a bad translation on any item, with an optional suggested correction. Reports go to Intento and carry no rating, account data, or user identity. Requires a Feedback API licence on the Intento account key.

Known limitations at this version

• Issues over roughly 10,000 characters exceed the per-request translation limit and fail; splitting long content is not implemented yet.

• Status lozenge labels stay in the source language.

• The project settings tab does not appear on company-managed projects; use site-wide settings for those.

• The app's own interface is English-only.

Before this changelog

The app was in production use inside Intento before its Marketplace listing. Those earlier builds were tracked in the repository's history rather than as customer release notes; per-version notes start with 3.7.0.