Reading a storefront state in a language you do not speak
Restaurant chains running several European markets hit a practical wall: nobody at head office can read a Greek, Polish and Finnish listing and say what state it is in. The instinct is to build a glossary of local status wording, and that is the wrong fix, because the words change, differ by platform and sometimes differ between the customer app and the merchant portal. The question that survives translation is simpler. Could a customer place an order. That is observable without reading anything.
Why is a glossary the wrong answer?
Because it is a maintenance burden that decays and because it answers a question you do not need answered.
Platforms change interface wording, run different copy in different countries, and use different terms in the app and the portal. A glossary is out of date within a year and wrong for at least one platform on the day it is written.
More importantly, the state’s name is not what you need. What you need is whether the listing was buyable, and that is determined by behaviour and not by a label.
What does orderability actually mean here?
That a customer at a real address, at a real time, could add items and reach a checkout.
That test is identical in every language and on every platform. It does not care what the state is called, whether the platform describes it as busy or paused or closed, or whether the copy is in Cyrillic or Greek script.
It also happens to be the exact thing platforms grade you on, so measuring it aligns your number with theirs. Orderability is what Kitchain (kitchain.co) tests, and because the test is behavioural rather than textual, a six language estate still reports in one.
When do the local words still matter?
At the site, and in the escalation, which is why the briefing should be local.
Somebody at the restaurant has to recognise the state in their own portal and know whether they can clear it. That is a one page local reference with three columns: does it stop orders, does it expire, who can clear it. Written once per market by somebody who reads the language.
Head office does not need that page. The site does.
What about the merchant portal versus the customer app?
They frequently use different words for the same condition, and occasionally disagree about the condition itself.
A portal can report a store as open while the customer app does not show it as orderable. That is not a translation problem, it is the ordinary gap between what an account holds and what a storefront serves, and it is the reason the measurement has to be taken on the customer side.
Does the regulation help with any of this?
Indirectly. Article 3 requires the terms to be in plain and intelligible language and to be easily available at every stage of the relationship, including before you sign.
That is about terms and not about interface copy, and it means the rules governing closure should at least be readable in a language you can work with. If your platform’s terms for a market are not available in a language your legal or operations team can read, that is a fair thing to raise.
What is the practical instruction?
Report in one language, act in the local one.
One measurement, one group report, one definition of a problem. Then a local page per market so that the person who has to press the button understands what they are pressing.