Translate prose only or adapt examples and destinations?
Keep code, commands, values and URLs unchanged by default. Any locale-specific example, unit or destination change needs explicit approval and a recorded exception.
Elysia Tools
Navigation
Workflow Playbook
Translate one approved Markdown technical document with a glossary, review meaning and protected content, reconcile links and heading anchors, and deliver verified Markdown with an HTML or PDF review artifact.
Hubs
This workflow is for maintainers, technical writers and SaaS documentation teams localizing one already approved Markdown page. It does not assemble new documentation from code or PDFs, publish a website automatically, or certify translation quality. Record the source revision, locale, assets, renderer and base path. Remove live credentials and confirm external AI processing is permitted before submitting source material.
Build a reference inventory with link extraction, then separately record code blocks, inline identifiers, commands, numeric values and warning sections. Extraction is an aid, not proof that every unusual Markdown construct was recognized. Agree which destinations remain shared and which may point to a localized page. Every intended exception needs an owner; do not let translation silently change an API version, a command flag or a required action.
Supply a source language when mixed-language text makes automatic detection ambiguous, and use an approved source-to-target glossary. The translator protects recognized code and link forms and restores them afterward. That protection is not a parser-level guarantee for every Markdown dialect. Relative destinations, reference definitions, escaped URLs and unusual fence forms need direct inspection. Search the complete draft for leftover placeholder tokens, missing sections and damaged syntax.
Use a target-language terminology audit to find unwanted variants, case differences and abbreviation issues. If optional contextual AI analysis was requested, check whether it actually ran or fell back to local rules. Neither mode proves correct meaning. A technical reviewer must compare the complete source and target, especially negation, prerequisites, parameter descriptions, table cells and caution text. Use text diff for literal protected passages and draft-to-approved changes; a large bilingual diff is not an accuracy score.
Compare source and target link and image inventories rather than merely counting links. A count can remain unchanged while a destination changes. Record approved localized destinations and preserve the context of relative images and cross-page paths. Static checking can identify recognized formatting, reference and fragment issues, but it sends no network requests and follows its own heading rules.
The critical failure is a preserved source fragment under a translated heading. Preserving the string does not create that ID. Use stable IDs only if the receiving system supports them; otherwise update both the heading-dependent reference and its destination. A checker can also flag custom IDs it does not understand. Resolve findings against the actual site renderer, including duplicate headings, Unicode slugs and cross-page anchors. Preview is useful for structure, but manually test navigation and assets in the receiving context. Do not label a URL available until a separate authorized availability check supports it.
Export only from the approved Markdown revision. Use the HTML converter for the chosen browser artifact or the report bundler for a PDF proof; they are alternatives, not a required round trip. A bundler can place source and target as separate sections, but does not produce synchronized side-by-side translation alignment. Preserve file order and label both versions.
Open the exact artifacts and inspect long code lines, tables, images and target-language glyphs. A preview may use different Markdown behavior from the export or the final site. Keep relative assets with their expected path or make an approved path adjustment, and never assume a PDF proves live-site navigation. Deliver Markdown, selected proof, glossary, source revision, link reconciliation, unresolved findings and reviewer approval. Store copies outside temporary output links. Generic authoring belongs in the documentation workflow; broader site typography and accessibility checks remain separate responsibilities.
Workflow playbook
Extract source link and image destinations, record code and value baselines, and use text comparison for revision control; collect the target glossary before translation.
Provide the source and target language, glossary and deliberate fragment-preservation setting. Save the complete restored draft, treating output protection as a mechanism to verify rather than a fidelity guarantee.
Audit the target with the approved target-language glossary and manually compare prose, code, numbers and warnings with the source. Use text diff to inspect protected content and draft-to-approved edits, not to measure translation accuracy.
Extract target destinations and compare inventories, run static checks and preview structure. Resolve translated-heading fragments and relative paths in the actual renderer; verify external destinations separately when authorized.
Keep code, commands, values and URLs unchanged by default. Any locale-specific example, unit or destination change needs explicit approval and a recorded exception.
Preserving a source fragment does not create its target after a heading is translated. Choose a supported stable-ID policy or update headings and links together, then test the receiving renderer.
Choose HTML for browser navigation and PDF for a portable approval copy. Both are alternatives; neither replaces the editable Markdown or testing in the actual documentation site.
Choose an HTML artifact or a PDF review bundle from approved Markdown. Inspect final code, tables, images and glyphs, retain relative assets and record reviewer approval; keep Markdown as the editable source.