Forthwith Docs

Everything your team needs to start translating your app strings with Forthwith.

This guide covers pricing, billing, organization management, invitations, and the CLI workflow. Use the section navigation to move through the docs.

Overview

Getting started

Product

A typical Forthwith rollout has four steps: choose the billing model that fits your translation volume, add a payment method for the organization, invite teammates with the right roles, and run the CLI against your project.

Billing setup

Review your plan, current usage, payment method, recent invoices, and cancellation status.

Organization setup

Invite teammates, assign one or more roles, remove members, and transfer primary ownership when needed.

CLI workflow

The CLI handles login, project configuration, translation execution, status checks, and CI-friendly automation.

Reference

This page is organized for scanning. Jump from the left sidebar to a section, or use the previous and next section cards at the bottom of each section.

Product

Billing

Plans

Forthwith supports pay-as-you-go, monthly subscriptions, and non-expiring prepaid word packs. The Billing page shows your current plan, usage in the active billing period, a default payment method, recent invoices, and whether cancellation is pending.

Standard

Ongoing

Subscription

$49.00/month

Includes 100,000 words each month, then $0.65/1,000 words for additional usage.

  • 100,000 words included each month
  • $0.65/1,000 words above quota
  • Best for ongoing localization in active products

Scale

High-volume localization

Subscription

$129.00/month

Includes 300,000 words each month, then $0.55/1,000 words for additional usage.

  • 300,000 words included each month
  • $0.55/1,000 words above quota
  • Best for high-volume localization across products and languages

Flex

Occasional

Pay as you go

$0.89/1,000 words

Best for trying Forthwith or running translation work only when you need it.

  • Pay only for the translation usage you run
  • Best for occasional localization work
  • Requires a card on file before translating

How usage is measured

Word usage includes both your source text and the instruction or prompt words sent to the model. The CLI shows the estimated breakdown and asks you to confirm before it submits translations.

Payment method timing

Flex requires a card on file and charges only for uncovered usage. Standard and Scale include monthly word allowances. Prepaid word packs require no subscription; buy them from Word packs and confirm each translation before it starts.

Prefer to pay once? Buy a word pack.

Choose 100K words for $80, 300K for $225, or 1M for $700. Words never expire. Subscribers keep pack words by default because their overage rate is cheaper. Optional Flex fallback is off until you authorize it.

Compare word packs

Usage

Current usage is tracked per billing period. Subscription plans show included words and when overage is active.

Invoices

Recent invoices are listed directly on the Billing page so billing members and owners can reconcile charges quickly.

Cancellation

Flex can be canceled immediately. Standard and Scale stay active until the current billing period ends, and pending cancellation can be undone before then.

Product

Inviting users

Organization

Invitations are managed from the Organization page. Invite a teammate by email, choose one or more roles, and send the invitation. Pending invitations stay visible until they are accepted, expire after 7 days, or are deleted.

Invite flow

  1. 1 Enter the teammate's email address in the invite form.
  2. 2 Choose one or more roles. The developer role is the default.
  3. 3 Send the invitation. Forthwith emails the invite link and shows the pending invitation in the organization settings.

What the page enforces

  • A pending invitation for the same email and organization cannot be created twice.
  • Existing members cannot be invited again.
  • Pending invitations show their assigned roles and expiration date so admins can verify access before acceptance.
  • Owners can delete a pending invitation at any time if the invite was sent to the wrong person or should be reissued.

Product

Organization roles

Access

Forthwith supports three organization roles, and a member can hold more than one at the same time. Roles control billing access, workspace administration, and day-to-day project work.

Owner

Full access to everything

Owners can manage members, billing, settings, API access , and projects. Owners can also transfer primary ownership and close the organization.

Billing

Manage payments and invoices

Billing members can manage payment methods, invoices, subscriptions, and other billing settings without changing workspace ownership.

Developer

Build and deliver projects

Developers handle translation projects and day-to-day delivery work without billing or ownership permissions.

Role combinations

Roles are additive. For example, a teammate can be both Billing and Developer if they need to manage invoices and run localization work, while the primary owner remains responsible for ownership transfer and organization closure.

Product

Ownership and closure

Governance

The primary owner has a small set of responsibilities that ordinary owners do not: transferring primary ownership, closing the organization, and handling situations where the current owner needs to leave the workspace.

Transfer primary ownership

  • Only the current primary owner can transfer primary ownership.
  • You can transfer ownership only to an existing member of the organization.
  • Transfer ownership before removing the current primary owner from the workspace.

Close organization

  • Only the primary owner can close the organization.
  • Closing removes members, pending invitations, and scoped API tokens.
  • Closure is blocked while translations are still processing.
  • If a subscription is still active, the organization can be closed only after the current billing period fully ends.

CLI

Install

Setup

The CLI is the main integration point for repositories. It discovers strings, shows the expected translation work, and writes localized files back into your project.

Select your platform

Install method

Open the Terminal and enter commands below:

brew install Forthwith-LLC/forthwith/forthwith

Choose the installer that matches your machine to get the exact command for your environment.

You can also download the CLI manually. Open the GitHub Releases page.

Supported frameworks currently include Android, iOS, React, React Native, Flutter, Phoenix, and go-i18n.

CLI

Check localization

Free · local · no login

forthwith check scans the localization files in your repository for concrete defects. The analysis runs entirely on your machine, does not contact the Forthwith API, and needs neither an account nor a .forthwith.yml file.

1

Install the CLI

Choose macOS, Linux, or Windows and copy the installation command for your machine.

View install instructions
2

Run your first check

Open your project directory and run:

forthwith check

Start with evidence, not a signup

Run the check immediately after installing the CLI. Nothing is uploaded and no localization file is changed. Review the report, fix findings yourself, or opt into Forthwith's paid repair workflow later.

$ forthwith check

[ERROR] Missing translation keys (2) · fixable · missing_key
  es, fr  locales/en/common.json:14  checkout.title
  Suggestion: Run 'forthwith check --fix' to translate only the missing entries.

Result: 2 error(s), 0 warning(s)
Details: forthwith check --full
Fix 2 supported findings: forthwith check --fix
Machine-readable: forthwith check --json

What it catches

Missing and empty values

Find keys absent from a target and translations with no value.

Malformed syntax and duplicates

Surface parser failures and duplicate keys with file locations.

Placeholder mismatches

Catch dropped or changed interpolation tokens before runtime.

Plural-form gaps

Verify the forms required by each target language and framework.

Untranslated values

Review target text that is still identical to its source value.

Protected-term drift

Detect changes to terms configured not to be translated.

Choose what to inspect

--full

Show every issue instead of representative rows.

--json

Emit the complete machine-readable report.

--target es,fr

Analyze only the selected target languages. The flag is repeatable.

--path <path>

Analyze only a selected source or resource path. The flag is repeatable.

--framework <name>

Override automatic framework detection.

--source-language <code>

Override source-language inference.

--severity error

Display only error or warning groups in human output.

--code <code>

Display only selected diagnostic codes in human output.

--warnings-as-errors

Return a failing exit code when warnings are found.

--fix

Run the paid, authenticated repair flow for supported findings.

--yes

Approve repair jobs without prompting; required with --fix --json.

--force

Skip only the uncommitted-changes safety prompt during repair.

--severity and --code filter only the human display; the CLI still analyzes everything in scope and calculates the same exit status. They cannot be combined with --json . --target and --path limit the analysis itself.

Repair supported findings

forthwith check --fix retranslates only supported findings: missing or empty values, plural gaps, placeholder mismatches, and protected-term drift. It requires an initialized project, authentication, and a paid subscription or pay-as-you-go confirmation.

Identical source and target values remain review-only because they may be intentional brand names or language-neutral terms. Reports and exit status always describe the post-fix scan.

Review intentional matches

forthwith check --review-identical opens an interactive, searchable checklist of values identical to the source. Confirmed values are added to do_not_translate ; cancellation writes nothing.

Exit codes and CI

  • 0 No failing issues were found.
  • 1 An error occurred or error-severity findings were found. Warnings also fail when --warnings-as-errors is set.
  • 2 The user cancelled an interactive operation.
# Fail on errors and warnings; no token or account required
forthwith check --warnings-as-errors

# Or retain the exhaustive report as JSON
forthwith check --json > forthwith-check.json

Want this check on every pull request? Follow the GitHub Actions setup below.

CLI

Update

Setup

Update the CLI with the same package manager or install path you used during installation.

Select your platform

Install method

brew update
brew upgrade forthwith

Manual download

Download the latest release for your platform, then reinstall it the same way: Open the Releases page.

  • On macOS, run the newer `.pkg`.

Use the matching update path so package manager metadata and installed binaries stay aligned.

CLI

Uninstall

Setup

If you need to remove the CLI, choose the same platform and package manager or script path you used during installation.

Select your platform

Install method

brew uninstall forthwith
brew untap Forthwith-LLC/forthwith

Use the matching uninstall path so package manager metadata and shell-installed files are removed correctly.

CLI

Quick start

Workflow
forthwith login
forthwith init
forthwith translate
forthwith status
forthwith whoami

That sequence gets you authenticated, creates a project config, runs a translation pass, and lets you confirm coverage and account context.

CLI

Authentication and profiles

Access
  • Use the forthwith login command to authenticate the default profile from the CLI in your browser. To use a specific profile name, add the --profile flag. Recommended
  • To use token-based login, first generate an API token at API access , then use the ( --use-token or --token ) flag to specify the token.
  • FORTHWITH_AUTH_TOKEN overrides stored credentials for commands that need authentication, and should really only be used for CI/CD.
  • List profiles with forthwith profile list , and set the profile you want to use with forthwith profile use .
  • forthwith logout revokes token(s) server-side and removes local credentials.
  • forthwith logout --all revokes all saved profile tokens, then removes all local credentials.

Automation access

Service tokens

CI/CD

A service token is an organization-owned credential for unattended automation, such as a localization workflow. It is separate from a person's API token, so the workflow can keep running if that person leaves the organization. Translation access is limited to one project.

Set up a service token

  1. As an organization owner, open API Access and find Service access. Give the token a name that identifies the workflow.
  2. For a localization PR workflow, enter the project ID from .forthwith.yml and select Translate. Read usage is selected automatically because the CLI checks usage before translating. Read usage alone works for usage monitoring; the read-only Check workflow needs no service token.
  3. Set a monthly word budget and choose an expiration from 1 to 365 days. Each service identity has its own budget, which resets each UTC calendar month.
  4. Select Create service token, copy the credential when it appears, and save it as the FORTHWITH_TOKEN GitHub Actions repository secret. The credential is shown only at creation or rotation; keep it out of your repository and workflow YAML.

Budget, rotation, and history

  • The server reserves source and instruction words when a translation job is created and releases the reservation for cancelled, failed, or expired jobs.
  • Rotate to invalidate the old credential and start a new expiration period of the same length, then replace the GitHub secret before the next run. Rotation keeps the same service identity and monthly budget.
  • Revocation is final. Revoked and expired tokens remain in the collapsed audit history; revoked tokens cannot be rotated. Create a new token to restore revoked access.
  • Translation jobs retain the service identity. When the CLI runs in GitHub Actions, it also records the repository, workflow run, and commit supplied by the workflow environment. These details help with audit history but are not verified GitHub identity claims.

CLI

Project configuration

Config

Create config with forthwith init , then edit it with forthwith config .

version: 1
framework: android
source_language: en
target_languages:
  - es
  - fr
source_paths:
  - app/src/main/res/values/strings.xml
do_not_translate:
  - Forthwith
tone: neutral
politeness: neutral
domain: general
audience: general

Editor selection order for forthwith config is VISUAL , then EDITOR , then the platform fallback ( vim , vi , or notepad.exe on Windows).

CLI

Translation workflow

Translate
  • forthwith translate processes new, changed, and missing target translations by default.
  • Plural output follows the target framework, not just the source file's shape. For CLDR-native formats such as iOS .stringsdict , Forthwith may expand English one/other into target categories such as Spanish or Italian one/many/other . For Phoenix/gettext targets, it writes only the forms the msgstr[N] slots can persist, such as one/other for Spanish or Italian.
  • --all forces a full re-translation.
  • --target accepts one language or a comma-separated list from target_languages .
  • --file limits the run to one configured source path.
  • --dry-run previews work without writing files.
  • --yes skips confirmation prompts, and --force skips the git safety prompt.
  • Exit codes are 0 for success, 1 for error, and 2 for cancellation.

CLI

Status, account, and automation

Visibility
  • forthwith status summarizes per-language translation coverage and supports --json output.
  • forthwith whoami shows the authenticated identity, organization, plan, and usage, with optional --json output. A personal token shows an email; a service token shows its name instead.
  • forthwith completion <shell> generates shell completions for bash , zsh , fish , and powershell

CLI

Environment variables

Runtime

FORTHWITH_AUTH_TOKEN

Overrides the stored auth token.

FORTHWITH_DEBUG

Enables debug output.

VISUAL / EDITOR

Controls which editor opens for `forthwith config`.

XDG_CONFIG_HOME

Influences config and credential directory resolution where the platform supports XDG conventions.

CLI

GitHub Actions

Automation

Use two separate workflows: a free, read-only check on pull requests, and an optional paid translation workflow that opens a localization pull request for review.

1

Check every pull request

Open the public check workflow, select Raw, copy its entire YAML, and save it in your own repository as .github/workflows/forthwith-check.yml . Or run this copyable command from the root of your repository:

Open public check workflow
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/Forthwith-LLC/forthwith-action/main/examples/forthwith-check.yml -o .github/workflows/forthwith-check.yml

Commit the file and open a pull request. The Forthwith localization check will report issues in the PR; the check itself needs no Forthwith account, token, or GitHub write permission. After its first run, you can optionally make that check required in a branch ruleset.

2

Open a localization PR

  1. Run forthwith init if needed, then commit a valid .forthwith.yml at your repository root.
  2. After completing Forthwith billing setup, ask an organization owner to create a service token in API Access . Select Translate; Read usage is selected automatically. Bind it to the project_id in .forthwith.yml, set a monthly word budget and expiration, and copy the token once. On GitHub, open your repository's Settings → Secrets and variables → Actions → New repository secret. Name it FORTHWITH_TOKEN and paste the token there. Do not put the token in your project files or workflow YAML. Read the service token setup guide. See GitHub's repository secrets guide.
  3. Copy the public localization workflow into your repository as .github/workflows/forthwith-localize.yml . Open the YAML below, select Raw, and copy it—or run the command from your repository root.
Open public localization workflow
mkdir -p .github/workflows
curl -fsSL https://raw.githubusercontent.com/Forthwith-LLC/forthwith-action/main/examples/forthwith-localize.yml -o .github/workflows/forthwith-localize.yml
  1. Edit both references to main if your default branch has another name. Set max-strings to the maximum distinct source strings you want to allow in one run. The example uses 100; start lower if you want a smaller first test, then raise it after checking usage. This is a separate CLI guardrail; the service token's monthly word budget is enforced by the server. A run over the string limit stops instead of translating only the first batch.
  2. If using the default GitHub token, open GitHub's Settings → Actions → General → Workflow permissions and enable Allow GitHub Actions to create and approve pull requests . The workflow itself requests only Contents and Pull requests write access. See GitHub's workflow permissions guide.

Test manually, then enable push automation

The public localization template starts with manual runs only, so committing it cannot start a paid translation. After it is on your default branch, open GitHub Actions → Forthwith localization PR → Run workflow. Review the generated PR and its usage before merging. Once you are satisfied, uncomment the push trigger in the workflow to translate future default-branch changes automatically.

A fine-grained GitHub PAT is optional. Without one, GitHub asks a maintainer to select ‘Approve workflows to run’ for checks on the generated PR. That starts CI; it does not approve the translation, satisfy code review, or merge the PR.

For automatic PR checks, create a fine-grained PAT limited to this repository with Contents and Pull requests write permissions, then save it as another GitHub Actions repository secret named FORTHWITH_GITHUB_TOKEN . The workflow uses the built-in GitHub token when this optional secret is absent.