Translation export implementation

These Odoo 18 tools generate POT templates using installed modules in a temporary database. They write to addon repositories; they do not translate PO files or activate translations in an existing application database.

Entry points

The repository exporter reads data/repos/18/18-repositories-pmisuite.csv from its own _pmiconfig checkout on each invocation. Local paths use folder_name (or name when the folder is blank) below /srv/pmiverse/_pmisuite18/repos/pmiverse. Every listed repository is included, including federation; duplicate folders are processed once. Missing or malformed catalogs fail before Odoo or database operations. Existing missing checkout/no-addon handling remains unchanged; the exporter does not clone repositories.

--list-repos prints the valid folder names without accessing Odoo configuration or databases. Bash completion for --only-repo uses this same interface, so catalog changes require no second hard-coded list. Reload the completion library in existing shells after updating it. --only-repo federation limits execution to that repository; without this filter, exports now cover all catalog repositories, not the former subset.

Both scripts read the configured Odoo instance's addons_path and append the selected repository root when needed. Command builders return argument lists, so paths remain individual subprocess arguments. Module installation must finish before export: extracting against an uninitialized database would not represent the installed module's translation terms.

--dry-run prints the planned operation without invoking Odoo or dropping a database. Source constants still identify the Odoo executable, configuration, and, for the repository command, available roots. CLI help owns the complete option list.

Publication and failure behavior

The single-addon command initializes its database, writes the POT directly, and drops the database after successful export. Initialization or export failure returns before cleanup; inspect the retained database separately. This command does not provide the repository command's comparison behavior.

The repository command drops its deterministic temporary database before initialization and attempts to drop it again in finally. It installs the filtered module set together, then exports modules individually. A module export failure contributes to the repository result without stopping the remaining exports. Temporary export files are removed by their own finally block. Database names are not unique per invocation, so overlapping runs for the same derived name are not isolated.

POT comparison ignores only the listed volatile header prefixes, such as creation/revision timestamps and generator metadata. It is a normalized text comparison, not a general PO parser. Equivalent exports keep the existing file, and new header-only exports do not create a new POT. Existing files can still be replaced when their meaningful contents change.

Maintenance

Keep CLI filters, completion, command builders, and this lifecycle description aligned when changing behavior. Do not import operational code to run exports as a documentation check. There is no dedicated translation-export test suite in this repository; new behavior should be verified with isolated subprocess fixtures before any separately authorized database/export acceptance.

See the developer guide for repository-wide interfaces and the documentation portal for other tools.