Projects and languages
Organize product text, choose source and target languages, and keep translation context with the project.
On this page
Choose a project boundary
A project groups keys, languages, and publishing configuration. Use one project for surfaces that share the same message identifiers and meaning. Separate unrelated products when their languages, release timing, or translation context differ.
Projects belong to an organisation. Select the correct organisation before creating or opening a project, especially if your account belongs to several teams. Project access follows the permissions granted in that organisation.
Set up languages
Each language has a code, a display name, and a main-language setting. The main language provides the source text for your workflow. In OTA delivery it also identifies the source locale used by supported SDK fallback.
Keep language codes consistent between ReRune, your locale files, and the application. Regional codes represent a language and region; use them when the content actually differs. The CLI records the project language list in rerune.json.
Add a language in project settings, translate the existing keys, and publish the values you want to deliver. Native resource-based apps may need resource generation or an app release to add bundled support. SDKs can expose fetched dashboard languages within the application, subject to their platform limits.
Write useful project context
- Description: explain what the product does and who uses it.
- Guidelines: specify voice, formality, units, capitalization, and terms that must remain unchanged.
- Notes: record background that helps someone distinguish a button label from a heading or status message.
Keep context current when the product vocabulary changes. Use dictionaries for reusable terminology and key-level metadata for message-specific details.