Connected modules and Apps

i18ntranslator is deliberately not self-contained. It leans on the platform for files, access control and AI, and it exposes its own events to other Apps.

Projects — required

Every package belongs to a project. Not optionally — structurally.

• Source language files are stored in the project's Files tab, and imports read from there. The App ships no uploader of its own.
• The project's file list is the version history of the source material.
• Project access is the outer permission gate: a user who cannot reach the project cannot reach its packages, whatever their App permissions say.
• Files pulled from GitHub are written into the project's Files before being imported, so a GitHub-sourced catalogue is as traceable as a hand-uploaded one.

Deleting a package never deletes the project files it was built from. The project is the source of truth; this App is a workspace on top of it.

Which projects appear

The project picker lists the projects the current user can reach: all of them for an administrator or a user with manage all projects, and the user's own project memberships otherwise.

Settings → AI — the shared provider layer

The App has no AI provider code of its own. It registers one operation, Translate strings (i18ntranslator), into the platform's AI operations list.

Under Settings → AI → Operations that operation gets:

• an enable toggle — the AI button only appears when it is on and configured,
• its own provider, API key and model, each falling back to the workspace default when left blank.

Every provider the platform supports works here with no extra code: OpenAI, Claude, Gemini, DeepSeek, Grok, and self-hosted engines such as Ollama.

Giving the operation its own key is what makes localisation cost measurable on the provider's own dashboard, separately from every other AI feature in the workspace.

Roles and permissions

The App adds four permissions to the standard role editor at Settings → Roles: view, translate, review, and manage. They are stored with the role like any core permission, and administrators hold all four implicitly.

Team members

Every change — a saved translation, a status change, an import, an export, a GitHub push, an accepted overwrite — is attributed to the user who made it and shown with their name in the history and the activity feed.

NizuEvents — outgoing webhooks (planned for v1.2)

Not connected yet. The design below is settled and the App is built to support it, but the two entity registrations have not been added to NizuEvents, so subscribing to i18ntranslator events is not possible in version 1.0.

When it lands, the App's package and export records will be subscribable like any other entity, so an external service can be notified when a translation is published. Two entities will be exposed:

• i18n_packages — a package created, updated or removed.
• i18n_exports — an export or a GitHub push (creation only; an export record is never updated).

Individual string writes are deliberately not exposed as events: a single AI run writes thousands of rows, and subscribing to that would fire thousands of HTTP requests. Package-level and export-level events carry the information anyone actually wants — "the French translation was published" — at a sane volume.

Whether NizuEvents is installed or not, nothing in this App changes and nothing breaks.

GitHub — external

A package can connect to one repository and branch through the GitHub Git Data API, using a fine-grained personal access token with Contents: read & write. The App creates real git commits (blobs, tree, commit, ref update), so a push of twelve language files lands as one commit rather than twelve.

It never force-updates a branch. A branch that moved underneath a push fails loudly and asks you to pull.

Clients and tasks — planned

The data model already carries an optional client and task link on every package, for a later version in which a client contact can be given translator access to their own project's package, and a translation session can be attached to a task so it shows up in the normal task flow and time tracking. Neither is exposed in the interface yet.

What it does not touch

• It does not modify the platform's own language files. The App translates your customers' applications, not NIZU itself.
• It does not write to any core table except project_files, and only when pulling from GitHub, and only into the package's own project.
• It ships no public endpoints, no API tokens and no CORS configuration. The public REST surface belongs to the Cloud API.