> ## Documentation Index
> Fetch the complete documentation index at: https://ngquct-docs-fix-500-query-results.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Development Overview

> Build TablePro from source, contribute, or write a database driver plugin

Two files in the repo root outrank these pages.
[`CLAUDE.md`](https://github.com/TableProApp/TablePro/blob/main/CLAUDE.md) holds the architecture
invariants and the rules a change has to meet before it merges;
[`CONTRIBUTING.md`](https://github.com/TableProApp/TablePro/blob/main/CONTRIBUTING.md) holds branch
names, the commit format, and the pull request checklist. Both are maintained next to the code they
describe, and where either disagrees with a page here, it wins.

What these pages add is the part neither file carries: the exact commands, the tool versions behind
them, and the plugin SDK.

<CardGroup cols={2}>
  <Card title="Setup" icon="wrench" href="/development/setup">
    Clone, download the libraries, generate the project, build.
  </Card>

  <Card title="Architecture" icon="diagram-project" href="/development/architecture">
    Module layout, plugin system, editor pipeline.
  </Card>

  <Card title="Building" icon="hammer" href="/development/building">
    Debug builds, the plugin compile check, tests, pull request CI.
  </Card>

  <Card title="Releasing" icon="ship" href="/development/releasing">
    Release builds, notarization, DMG, static libraries, the release tag.
  </Card>

  <Card title="Code Style" icon="indent" href="/development/code-style">
    Lint and format config, naming, the rules CI enforces.
  </Card>

  <Card title="Plugin Development" icon="puzzle-piece" href="/development/plugin-development">
    Write a driver plugin against TableProPluginKit.
  </Card>

  <Card title="Testing a Custom Plugin" icon="flask" href="/development/testing-plugins">
    Load a locally built plugin in a debug build.
  </Card>

  <Card title="Plugin Registry" icon="box" href="/development/plugin-registry">
    Publish and distribute database driver plugins.
  </Card>
</CardGroup>

## Translating the app

Interface strings live in one `.xcstrings` catalog that interleaves every language inside every
key, so a hand edit means working next to languages you do not speak. `scripts/localization.py`
gives one flat JSON file per language instead:

```bash theme={null}
scripts/localization.py status              # coverage, per language
scripts/localization.py export vi           # writes Localization/mac.vi.json
scripts/localization.py import vi           # merges the edits back into the catalog
```

Edit the `translation` values in the exported file, then import. Add `--target ios` for the iPhone
and iPad app, which has a catalog of its own. Commit the catalog and not the export: `Localization/`
is gitignored, and a merge rewrites only the strings that changed, so the diff shows the
translation and nothing else.

Run `scripts/localization.py verify` after changing the script. It re-reads and rewrites each
catalog and checks the result is byte for byte identical.