Soft launch Dialecto is still in testing, and details on this site may change as we finish it.

Source call-site rewrite

Renaming a msgid is normally two changes that drift apart: the catalog entry, and every place your source still calls gettext("old text"). Dialecto treats a rename as one operation: the catalog change ships as a minimal diff, and the matching call-site rewrites ship with it.

How the halves split

The work is deliberately split across the trust boundary:

  • Dialecto computes. For every staged rename, the usage index (built from the snippets your scans send) knows each call-site. The language-aware rewriter produces, per site, an exact match → replacement: the file path, the line range, the old bytes as the scan last saw them, and the new bytes.
  • Your repo applies. The repo-side action, dialecto-eu/source-rewrite, takes those computed rewrites and applies them against the real files, re-anchoring each one on its recorded bytes at the recorded location. Dialecto never pushes source-code changes itself — the transform is applied where the code lives, on your side. The action is public on GitHub at dialecto-eu/source-rewrite. Use it as dialecto-eu/source-rewrite@v1, or pin it to the commit of a release such as 1.0.0 if you prefer every update to be a deliberate change in your workflow. Dialecto opens its pull requests on branches that start with dialecto/, and the action only applies rewrites on pull requests from such branches.

When the rewriter refuses

A rewrite only happens when it’s unambiguous. A call-site the rewriter can’t transform safely — a variable msgid (gettext(some_var)), a near-miss literal, or bytes that have drifted since the last scan — is never guessed at. It’s collected and listed in the pull request as update manually, with the file and line, so nothing is silently wrong and nothing is silently skipped.

What a rename does not do

A Dialecto rename is a copy edit of the source label, not a change of meaning — so the rewrite does not mark translations fuzzy, and the existing translations for the entry carry over. If you are changing meaning, edit the translations too; the merge gate and review flow will catch what’s missed.

Requirements

  • The repo’s call-sites must be indexed — i.e., scans include usage snippets (they do by default; see Scanning & CI).
  • The rewrite-apply step runs via the repo-side action, which is public on GitHub but does not have a v1 tag yet. Renames staged without the action still ship the catalog diff and list every call-site as a manual follow-up.
  • Call-site rewriting is per-runtime. Elixir/Phoenix gettext is the implemented adapter (see the Elixir guide), and key renames in flat JSON catalogs are built too (see the JSON guide). Rails YAML has no call-site rewriting.