Skip to content
Translatable Docs

Projects & languages

Translatable is organized around projects and languages. Understanding how they fit together will help you structure your workspace cleanly and avoid surprises as your app grows.

What is a project?

Section titled “What is a project?”

A project represents a single application, product, or logical unit you want to localize.

Typical examples:

  • A web app
  • A mobile app
  • A public website
  • A backend service that serves localized content

Each project contains:

  • A set of translation keys
  • A list of languages
  • Translation values for each key × language combination

Most teams create one project per app.

What is a language?

Section titled “What is a language?”

A language represents a locale you want to support, such as:

  • en (English)
  • fr (French)
  • de (German)
  • es-ES (Spanish – Spain)

Languages are added per project, not globally. This allows different projects to support different language sets.

How projects and languages work together

Section titled “How projects and languages work together”

Inside a project:

  • You create keys
  • You add languages
  • Each key can then have a translation value for each language

Example:

  • Project: Web App
  • Languages: en, fr, de
  • Key: COMMON.SAVE

This results in up to 3 strings (one per language).

Adding and removing languages

Section titled “Adding and removing languages”

Adding a language

Section titled “Adding a language”

When you add a new language to a project:

  • Existing keys are created with empty values for that language
  • These empty values do not count as strings until a value is saved

You can then:

  • Translate manually
  • Request AI suggestions
  • Bulk-translate the language

Removing a language

Section titled “Removing a language”

Removing a language:

  • Deletes all translation values for that language
  • Immediately reduces string usage
  • Cannot be undone

Use this carefully in production projects.

One project or many?

Section titled “One project or many?”

Here are some common patterns:

Section titled “One project per app (recommended)”

Best when:

  • Each app has its own release cycle
  • Language support differs per app
  • Teams work on different products

Multiple projects for one app

Section titled “Multiple projects for one app”

Useful when:

  • You want to separate marketing copy from app UI
  • Different teams own different parts of the product
  • You want stricter access control (later)

Project limits by plan

Section titled “Project limits by plan”
  • Free plan: 1 project
  • Premium plan: unlimited projects

If you reach your project limit, you’ll need to upgrade before creating a new one.

Best practices

Section titled “Best practices”
  • Use clear project names (Web App, Marketing Site, Mobile App)
  • Add languages only when you’re ready to translate them
  • Avoid creating multiple projects for the same app unless you have a clear reason
Section titled “Related concepts”
  • Strings & keys: how translation values are counted
  • Plans & limits: how projects and languages affect usage