Troubleshooting
Section anchor links do not work in translated docs
A link like [label](other.md#section-id) may open the correct translated file but fail to scroll to the intended heading — or jump to the wrong section. The #… fragment no longer matches any heading id in that locale.
Common causes:
- Source headings never had explicit anchor ids; the site derives slugs from visible heading text, which changes after translation.
- You renamed a heading in source but the preceding
<a id="…"></a>line is missing or still has the old id. - Anchor links use a
#…fragment guessed from English words instead of the idwrite-heading-idswould generate.
Fix
- Run
ai-i18n-tools write-heading-idson your source.md/.mdx(samedocs[]/contentPathsastranslate-docs). It inserts<a id="slug"></a>before each ATX heading, or refreshes an existing anchor when the heading text no longer matches the current slug. - Point anchor links at those ids — e.g.
[setup](guide.md#first-run)where#first-runmatches the anchor line above the target heading, not a slug inferred from the English title alone. - Re-run
translate-docs(orsync --force-update) so every locale copy includes the updated anchor lines.
Use --dry-run on write-heading-ids first to preview changes. See Anchor links for the full pattern.
Image or asset links 404 in translated docs
A markdown link or  works in English but returns 404 in translated copies — often because the URL still points at the source-locale folder or an English-only static path.
Fix
- Confirm your asset layout matches your
docsOutput.style(flat vs doc-system). See Link rewriting and Images & Screenshots. - Add or adjust
docsOutput.postProcessing.regexAdjustmentsto swap locale segments or bridge absolute/img/…paths. For flat layout, remember the flat link rewriter runs beforeregexAdjustments— match patterns against the already-prefixed URL. - Ensure locale-specific asset files exist at the paths the rewritten markdown references (
translate-docsrewrites URLs but does not copy raster files).