The article comes in English. The category list comes in Ukrainian. We pick one category from the list, attach it to the article, and hand it off to the translator. The categorization happens before any of the prose is translated, in a language the prose was not written in, and we never reconcile the two languages explicitly.
This is one of those design choices that sounds wrong the first time we describe it. It works, and the reasons it works are more interesting than the reasons we thought it might not.
Why we categorize the source, not the translation
The intuitive order is: translate the article, then categorize it. The article in Ukrainian, the category list in Ukrainian, the match made within one language. It feels cleaner. The classifier reads both sides of the comparison in the same dialect.
We do not do this. We categorize the article in its source form, in the language it was written in, against a category list in a language it has not been translated into yet.
The reason is that the translation is downstream. A translator will choose words. Those words will pull the article in directions the original did not. A theological reflection on suffering, translated by someone with a homiletic ear, may end up sounding more devotional than it began. The same article translated by someone closer to academic theology may come out reading like commentary. The translation is a derived artifact. It is not the article. The category should describe the article, not the version of the article we are about to ship.
If we wait to categorize until after translation, we are categorizing the rendering, not the source. The pipeline shape we want is the opposite: categorize the thing that came in, then translate the thing that came in, then publish both together.
What the category name is doing
The category list arrives as a JSON array. Each entry has an id and a name. The name is in Ukrainian. To pick a category, the classifier reads the article in English, reads the list of Ukrainian labels, and chooses one.
It does this without an explicit translation step. The model does not translate the category names into English and then match. It does not translate the article into Ukrainian and then match. It does the matching directly.
What the model is doing is closer to noticing that a Ukrainian label is a pointer to a concept the editor has in mind, and the article is a body of text that may or may not point to the same concept. The matching is happening in concept space, not in the surface form of either language. We are not comparing words. We are comparing the things the words are about.
This works because the categories on a theology site are not arbitrary. They name well-defined concepts that exist in both languages and in the underlying theological tradition. A category for doctrinal writing points to the same set of articles whether the label is rendered in English or in Ukrainian. A piece on the Trinity is about the Trinity regardless of which language is naming the bin.
Where this breaks down
It breaks down at the edges of the taxonomy.
The Ukrainian label is the editor’s chosen name for a category. It is not a definition. The editor knows what kinds of articles they put there. A literal translation of the label might miss the editor’s working definition. A category whose name translates as “Sermons” might, in practice, mean “expositional preaching texts the community has produced,” not “any sermon-shaped piece of writing.” A translation of the label would not tell us that. The history of what the editor has put there would.
We do not have that history. The classifier sees only the live list of category names, not the articles in each category. It cannot infer the editor’s working definition from past use. So when the editor’s sense of a category drifts from what the label literally says, the classifier picks based on the literal name and gets the article close, but not always exactly where the editor would have put it.
In practice this happens for names that have a colloquial meaning alongside a technical one. A label that translates as “Practical” might mean, locally, “everyday Christian life pieces aimed at lay readers,” not “any practical-application article.” The classifier does not have that local context. It picks based on the closest thing the label says.
The fix, when this matters, is not to translate harder. It is to ask the editor to rename the category or to add a description field. The label is the only interface we have to the editor’s intent. If the label is wrong, we cannot make up the difference with better classification logic.
What this does to the pipeline
Categorizing in the source language means the classification is settled before the translator gets the article. The translator sees the category, knows where the piece is going, and can lean their word choices toward the conventions of that section. The category becomes part of the brief the translator works from, not a label attached after the fact.
This is the part we were not expecting. We chose to categorize early for a clean pipeline shape. The side effect was a translator with more context. The category was not just a routing decision. It turned out to be a constraint on the translation, in a useful way.
We do not know whether a translator working without the category in hand would produce a different rendering. We have not run the experiment. But the translators we work with read the category at the top of the brief and use it. The early classification gives them something to anchor to.
The article was written in one language. The category list lives in another. The classifier never reconciles them. The translator does, by reading both and choosing words that fit.