jekcms core runs one site in one language -- there is no built-in multi-language post system. This guide covers the two real options: separate installs per language, or single-language posts on one site, plus how to keep translations from drifting apart.
The Real Model: One Site, One Language
Before choosing a workflow, it helps to be clear about what jekcms actually does out of the box: a single jekcms installation runs as one site in one language. There is no lang column on the posts table, no translated_from meta key, and no per-post title_tr/content_tr fields in the product core. If you want a bilingual presence, you are choosing between two real options, not selecting from a built-in multilingual content system.
Option 1: Two Separate Installs
The straightforward approach is running two jekcms installations — one for each language, either on separate subdomains (en.example.com / tr.example.com) or separate domains entirely. Each install has its own database, its own posts, and its own admin. Nothing syncs automatically; you write and publish each language independently. This is the approach that scales cleanly and is what we would actually recommend if both languages need serious editorial investment.
The tradeoff is duplicated admin work: two logins, two sets of settings, two places to manage media (unless you deliberately share an uploads directory). For most bilingual projects, this overhead is smaller than the cost of maintaining a homegrown sync layer.
Option 2: One Language Per Post, Manually
If your content is mostly single-language with the occasional translated piece, you can run one jekcms install and simply write individual posts in whichever language makes sense — a post is a post, and nothing stops you from publishing some in Turkish and some in English on the same site. There is no hreflang automation for this case; you would add <link rel="alternate" hreflang="..."> tags yourself if you needed them, since jekcms's core does not generate cross-post hreflang pairs.
What jekcms's UI Translation Layer Actually Does
jekcms does have real, built-in translation helpers — but they operate on interface strings, not post content. __() and jek_t($tr, $en) translate labels, buttons, and admin/theme UI text based on the site's configured language; ct() does the same for the customer-facing account area. None of these touch the content of a post. If you are looking for a mechanism that stores two language versions of the same article inside one post record with automatic hreflang output, that does not exist in the product — the workflow above (separate installs, or separate posts) is the real path.
Preventing Content Drift
Whichever option you choose, assign a specific person responsible for each language version. The most common long-term failure mode is content drift — one language gets updated after a product change or correction, and the other does not. A simple checklist that runs whenever source content changes, with a manual cross-reference between the two installs or posts, prevents drift from compounding over time.
Translation Quality and Review Workflows
Machine translation has improved dramatically, but it still produces awkward phrasing in technical content. The most effective workflow we have seen pairs machine translation with a native-speaking editor who specialises in the subject matter. The machine handles the bulk translation in minutes, and the editor refines terminology, adjusts sentence structure for natural readability, and verifies that code examples and technical terms remain untranslated where appropriate. Treat the editorial review as a mandatory step rather than an optional pass that gets skipped under deadline pressure.
