The fear behind this question is a real one: a 180-dish menu, typed once in Chinese and once in the local language, then kept in sync forever every time you change a price or drop a dish. Nobody does that for long. The second column goes stale, the printed menu and the screen disagree, and a server ends up selling something at last year’s price.
One record, two name fields
The way out is structural rather than clerical. A dish is a single record in the system, and it carries both names as fields on that record. Price, tax class, station routing, modifiers — all of that lives once. When you change the price you change the record, and the counter, the QR ordering page and the receipt all read the new number, in whichever language the reader has.
So there is no second menu to keep in sync. There is one menu with two labels.
Who fills the second column
We do, during setup. Bring whatever you have — an Excel file, a Word document, a PDF from your printer, even a photograph of the laminated menu on the wall — and the catalogue gets built for you, with the local-language column filled in as part of it. That is included in onboarding, not billed as a translation project. The same applies if you are switching from another system.
After that, you maintain the Chinese column and tell us when a language needs revisiting.
The part you should not skip
Have one local member of staff read the finished menu out loud before you go live. This takes twenty minutes and it is the highest-value twenty minutes in the whole setup.
Dish names are the weak point of any translation, machine or human, because they are cultural rather than literal. 干煸四季豆 translated word by word is not what a Peruvian guest would order it as. 三分糖 has a real local phrasing in Penang and a different one in Bangkok, and your staff know it — see sugar and ice levels without duplicate items. A server who reads the menu once will flag five names that are technically correct and commercially wrong. Fix those five and the menu is done.
