Slovenian as our fourth language, without trampling on human translators

In September 2026 we added Slovenian as the fourth language of our CRM and our websites, alongside Italian, English and German. Put like that, it sounds like one more entry in a drop-down menu. In practice it was groundwork, and it forced us to decide what a translating machine should do and, above all, what it must never do.

We describe here how we set it up, because the choices that matter aren't the technical ones. They are the rules that let automation and people work side by side.

A language lives in many places

The first thing you discover when you add a language is how many corners of the system take the existing list of languages for granted. Slovenian had to find its way:

• into the flags, that is, the selector used by website visitors and by anyone working in the CRM;
• into the filters, because anyone searching for a contact or a property must be able to filter by Slovenian too;
• into the text templates, the replies and messages we use every day;
• into the dialling codes: a number beginning with +386 now suggests Slovenian as the contact's language.

We'll come back to that last point, because "suggests" is a carefully chosen word.

The daily process: a little at a time, only where there's a gap

Property descriptions are written in Italian first. To get them into Slovenian we set up an automated process that runs once a day and translates from Italian.

Two constraints define it.

The first: it works on just a few properties per run. We don't want a flood of new text all at once, impossible to review. A slow trickle that one person can keep up with, checking a few listings at a time, is far better.

The second: it only writes into empty fields. If a property already has Slovenian text, the process moves on. It doesn't overwrite, it doesn't "improve", it takes no liberties.

Human text always wins

The delicate case is when a person steps in. Perhaps the machine translation is accurate but sounds stiff; perhaps it misses a nuance that only someone who knows the property can supply. Someone opens the listing, fixes the Slovenian and saves.

From that moment the process never touches that text again. Ever. A manual save is an explicit signal: a person has been here, and their work takes precedence over any automation.

This is the rule we care about most, because it's what makes automation bearable. Anyone who corrects a text and finds it rewritten by a machine the next day stops correcting. And a system in which nobody corrects anything any more is a system that quietly gets worse.

The fingerprint of the Italian

One problem remains: when should it retranslate? If the Italian changes, the automatically generated Slovenian goes stale. If the Italian doesn't change, retranslating is pure waste, and it also produces text that shifts from one day to the next for no reason.

The solution is simple: the process remembers the fingerprint of the Italian text it translated from. On the next run it compares that fingerprint with the current Italian. If they match, it does nothing. If the Italian has changed, the machine translation is redone.

Naturally, this only applies to text the process wrote itself. Slovenian saved by hand stays put, even if the Italian moves: there, a person decides, not a fingerprint comparison.

Recognising a language doesn't mean replying in it

This is the least technical and most important decision in the whole project.

Having Slovenian in the CRM means we can recognise that a client probably speaks Slovenian: the dialling code says so, and so does the language they browsed the site in. The natural temptation would be to reply in Slovenian, with a ready-made template.

We decided against it. At the moment nobody at the agency speaks Slovenian, and a first message in a language we then couldn't sustain on the phone or at a viewing would be a false promise. That's why our texts state clearly that support is provided in Italian, English and German. Property listings can be read in Slovenian; customer support, for now, cannot.

Recognising a language is information. Replying in that language is a commitment. The two shouldn't be confused.

Ready for when the decision changes

This doesn't mean we've done half the job. Every text template that exists in the other three languages also exists in Slovenian. They're written and reviewed; they simply aren't used for replies.

The day someone who speaks Slovenian joins the agency, switching on support in that language will take a single line. We chose to pay the cost of preparing everything now, and to keep the business decision, which belongs to people, separate from the infrastructure, which should already be in place.

A style guide, not just a model that translates

Translating well into a language none of us has mastered calls for written rules. We followed a style guide dedicated to Slovenian, which settles certain choices once and for all:

• the polite form of address, to be used consistently in every client-facing text;
• the Slovenian name of the city, rather than a transliterated Italian form;
• the right word for "flat", because in property language not all synonyms are equivalent;
• plurals with four forms: where Italian distinguishes only between singular and plural, Slovenian has more cases, and a text saying "two bedrooms" or "five bedrooms" has to respect them.

Without a guide, every translation run risks choosing differently, and the result is a site whose register changes from one listing to the next. With the guide, the choices become stable and checkable.

What we're taking away

Adding a language taught us three things that apply well beyond Slovenian.

1. Automation fills gaps; it doesn't decide. It writes where there's nothing and stops where there's something.
2. Human work is a signal to be respected for good, not an exception to be managed.
3. Infrastructure can be ready before the promise. Having everything in Slovenian doesn't oblige us to speak Slovenian: it simply gives us the chance to do it properly, on the day we can keep that promise.