Publishing in two languages: content, workflow and interface in NoktaTR

01From magazine to screen

NoktaTR is a Turkish and English digital publishing platform for the culture, art and literature magazine .tr. It consists of a website, an administration interface and an API. The reader-facing website and the workflows for preparing and managing content are parts of the same system. The web and administration interfaces, built with Next.js, work with NestJS services and Prisma data access. This is a company project; I contributed to application layers, content management workflows, and development and delivery.

Turning magazine content into an enjoyable web reading experience is only half the work. The other half is giving the editorial team a sustainable way to manage that content. When these two halves are considered separately, you end up with either a site that is pleasant to read but hard to manage, or one that is easy to manage but ordinary to read. That is why I try to think about both halves at the same time.

02Three decisions, one decision

The most important idea I took from this project is that in digital publishing, content structure, editorial workflow and interface hierarchy are not independent decisions. How you model the content determines how the editor prepares it. How the editor prepares it determines what the reader sees first on the page. And the reader's experience comes back to ask something of the content model. During development I try to consider all three together.

The content model, the editor's workflow and the reader's eye are three faces of one decision.

03Content structure

A magazine piece is not just a title and a body. Each part, such as the author, category, images, quotes and related content, corresponds both to a field in the administration interface and to a place on the reader's page. When building the content structure, I think the question to ask is not “which fields do we need” but “what will this field tell the reader, and how will the editor fill it in”.

When the structure is too loose, every piece looks different and the interface loses consistency. When it is too rigid, room for editorial expression narrows. In a field like culture and literature, where form is part of meaning, striking this balance matters even more. So when settling the structure, I think it is a good habit to take a few different kinds of content as examples and check whether each fits the same mold.

04Editorial workflow

The administration interface is the publishing team's daily workspace. However steps like preparing, reviewing and publishing a piece are expressed in the panel, the team's work becomes that much easier or harder. What I value in workflows like this is that the panel reflects the editor's way of thinking rather than the technical data model. An editor thinks “I am preparing a piece”, not “I am creating a record”.

The website, administration interface and API working through a shared publishing model is decisive here. If content entered in the panel and content shown on the website are fed by the same model, the editor can more easily anticipate how a change will reach the reader. When the model diverges, small but tiring differences appear between what is seen in the panel and what the reader sees.

05Two languages, one publishing structure

Turkish and English content are considered together within the product's publishing structure. In bilingual publishing, I think the most critical question is how the two languages are connected. Are the two language versions of a piece two faces of the same content, or two independent pieces? The answer affects the data model, the editor's workflow and how the reader moves between languages. The first approach binds the languages tightly, the second gives more freedom; both have a cost.

Language here is not an interface setting but a dimension of the content itself. Title lengths, the rhythm of the text and typographic balance can change from one language to the other; the interface hierarchy needs to stay balanced in both. That is why I prefer to think of a bilingual publication not as a translation layer added later but as a structure designed from the start.

06The delivery side

Because my role also covered development and delivery, I had to look at the publication from the angle of staying live as well. A change on a publishing platform affects not only the code but also the published content and the editor's habits. That is why I think the question to ask at delivery is not only “does it work” but also “did anything break for the reader or the editor”. In publishing products, trust is built by the reader and the editor meeting the same thing every day.