The question behind the term
Translation added at the end creates duplicated routes, stale error text and metadata that points at the wrong canonical page. Locale is part of data identity and rendering from the first content model.
A reviewable approach
Use locale-aware fields, stable translation relationships and server-rendered lang, dir, canonical and hreflang values. Keep identifiers separate from labels and make validation messages, dates, numbers and generated emails locale-aware.
- Model translations as linked content
- Localize status independently where needed
- Test mixed-direction inputs and errors
- Keep canonical metadata server-side
The boundary to keep visible
Machine translation cannot establish product terminology or legal meaning by itself. Clinical and security language needs domain review in each language.
Publish a locale only when its page exists
Give each English and Persian page its own canonical URL, document language and complete metadata. A reciprocal hreflang pair belongs only on pages whose translations are actually published and indexable. A missing translation is not solved by sending a crawler to a 404 or by canonicalizing Persian text to English.
Test the HTML response before JavaScript runs: title, description, H1, canonical and language links should already be there. Then test the interface at narrow widths with real mixed Persian and Latin names, numbers and URLs. A route may have correct tags while a broken language switch still sends people through a redirect or drops their context.
References and further reading
Frequently asked questions
Should an English page advertise a Persian hreflang URL before translation?
No. Hreflang should point to a canonical, indexable page that actually provides the corresponding content.