# Commands for the database, settings and translations

These commands change what sits beside your code: the database's
migrations, your local settings, and the wording of your app in each
language.

| Command | Does |
|---|---|
| `jadpo migrate new <purpose>` / `apply` / `status` | Writes, runs and lists migrations |
| `jadpo config move <constant>` | Makes a constant a setting |
| `jadpo config set <field>` / `check` | Sets or checks your local settings in `.env.local` |
| `jadpo translations missing` / `unused` / `update` / `accept` | Shows and records the state of each language's wording |
| `jadpo translations builtin` | Lists Jadpo's own messages your app can show |
| `jadpo translations export` / `import` | Exchanges wording with translation services |

## `jadpo migrate`

`new` writes the next migration, or finishes the latest once its
decisions are written ([Migrations](migrations.md)). `apply` and
`status` take the database's URL with `--url`, and `--store` when there
are several. Otherwise they read it from the connection's setting, in the
environment and then `.env.local`.

A missing purpose will be asked for at a prompt, as the [CLI design
language](../cli-design-language.md) draws it, once prompts are built.
Until then the command names a purpose to use.

## `jadpo config move`

`jadpo config move <constant>` turns a constant into a setting: a
`config` field of its name and type, with its value as `default:`. It
deletes the constant and rewrites every read to `config.<name>`
([Making a constant a setting](settings-config-jadpo.md#making-a-constant-a-setting)).

Name the constant as code reads it (`security.max_login_attempts`), or
after its domain. It lists what changed, file by file, then the setting
and its variable. It refuses with `configuration.move_type_unsupported`,
`configuration.move_name_taken` and `configuration.move_read_unsupported`,
every reason at once, and changes nothing. A move whose result wouldn't
check is undone. It takes `--json`.

## `jadpo config set` and `jadpo config check`

`check` lists each setting as `set`, `default`, `missing` or `invalid`,
with its variable, against the environment and then `.env.local`. It
reports each problem as `configuration.value_missing` or
`configuration.value_invalid` and never prints a value. It takes `--json`.

`set` asks for one value at a prompt, hidden for a secret, so the value
never goes on the command line. It refuses `--json` and a missing
terminal. It checks the value against the setting's type, then writes
`.env.local`: only as an ordinary file, through a private temporary file,
and only if the file hasn't changed since it was read. It adds
`.env.local` to `.gitignore`.

## `jadpo translations`

Each of these takes `--json` ([Tooling for
translations](10-configuration-and-time.md#tooling-for-translations)).

- `missing [<locale>]` lists, under the language file each is in, the
  wording a locale lacks and what a locale still in progress falls back
  on. It also lists translations made from wording that has since changed,
  and wording not yet accepted.
- `unused` lists the messages no code calls, and the app's wording of
  library packages' text that shows nothing.
- `update` records each translation's source in
  `translations/sources.jadpo_record`.
- `accept <locale>` accepts a locale's changed wording.

`missing` and `unused` succeed whatever they list. `update` and `accept`
stop on syntax errors, write one status line for each record, and say
`still stale` of a translation nobody redid. A misspelt action or locale is
`cli.translations_arguments`, with the nearest name.

`jadpo translations builtin` lists Jadpo's own messages your app can
show, by feature: their fields, the wording Jadpo ships and the locales
that still need it. It lists only the messages of features your app has
on, takes `--json` and succeeds whatever it lists. `missing`, `update` and
`accept` take the root `translations/` folder's wording of these messages
in with the rest ([Jadpo's and packages'
text](10-configuration-and-time.md#jadpos-and-packages-text)).

`jadpo translations export [<locale>]` and `import <file>` exchange
messages, their descriptions and their wording with translation services,
as XLIFF 2.0 or JSON. Each takes `--json`.

- `export` writes `build/translations/<locale>.xlf` for each translated
  locale, or the default locale's source file. `--format json` and
  `--out <folder>` change the format and the folder.
- `import` checks what comes back as `jadpo check` would. It writes the
  language files and the record, or nothing. It refuses with the language
  files' own rules, at the unit of the file, or with
  `translation.exchange_unit_unknown` or
  `translation.exchange_file_invalid`.

Library packages' text is exchanged under each package's folder name, and
written back as the app's, in the root file.

Not built yet: `jadpo seed <name>`, which runs a seed and refuses
production ([Seeds](seeds.md)).