Skip to content

Projects

A project in Comvi represents a single application, website, or product that needs translation. It is the top-level container that holds your languages, namespaces, translation keys, and CDN configuration. If you ship multiple apps, you can create a separate project for each — though namespaces often handle module-level separation within one project.

Every project maps to one translatable codebase. For example:

  • marketing-site — your public website
  • web-app — your SaaS application
  • mobile-app — your React Native or Flutter app
  • docs — your documentation site

Each project is isolated — languages, keys, namespaces, API keys, and CDN deployment are all project-scoped. Settings in one project do not affect another.

  1. Open the dashboard

    Log into app.comvi.io. You land on the Projects page for your organization.

  2. Click “New Project”

    Enter a name for your project. Choose something short and recognizable, like the repository name of your app.

  3. Select a source language

    The source language is the language your developers write in — typically English (en). This becomes the reference language that translators work from and cannot be changed after creation, so choose it deliberately.

After creation, Comvi automatically sets up a default namespace and takes you into the project, opening the Translations view.

From the project sidebar you can reach:

  • Translations — browse and edit keys and values (the default landing view)
  • Import and Export — move translations in and out as JSON or i18next-v4 JSON
  • Languages — add target languages and manage the source language
  • Glossary — project-specific terminology
  • Translation Memory — reuse matches from past translations
  • Settings — see below
  • API Keys and Webhooks — credentials and outbound event delivery

Open Settings from the sidebar to configure your project. It is organized into a few sections:

  • Project name and description — update these at any time
  • Source language — the locked reference language for all translations
  • Delete project — permanently removes the project and all its data

Control which organization members can access this project and what they can do inside it. Organization roles set the baseline, and per-project assignments can narrow access, restrict a member to specific languages, or grant access to members whose org-level default would exclude them.

See Roles & Permissions and Team Management for the full access model.

Controls how translations are published and delivered to your app. You can enable or disable CDN publishing, choose which languages and namespaces to deploy, and filter by translation status.

See CDN Deployment for more details.

Configure which MT providers are enabled for this project, set a primary provider, pick LLM models, and choose whether MT suggestions should auto-apply as Not reviewed.

See Machine Translation for more details.

API keys are project-scoped credentials for authoring workflows — the CLI, CI pipelines, and any server-to-server call against the REST API. They are not used by the SDK at runtime; production apps read translations from the CDN. Keys carry their own permissions independent of user accounts.

Webhooks deliver project events such as translation, key, namespace, import, export, and comment changes to an HTTP endpoint you control.

See API Keys and Webhooks for details.

Your organization can contain as many projects as your plan allows. Access to each project is determined by the member’s organization role together with any per-project overrides, so you can keep some projects open to the whole team while scoping others to a specific group.

You can delete a project from the General section of the project settings page. Deletion is permanent — translation keys, values, history, comments, namespaces, CDN configuration, API keys, per-project member assignments, and machine-translation settings are all removed and cannot be recovered.