Arabic-First Restaurant POS: Bilingual Receipts, Labels and Menus That Work in Arabic

What "Arabic-first" actually means in a restaurant POS

Many systems advertise Arabic support when they only translate the buttons. A restaurant needs more than that, because the customer and the kitchen touch the system at five different places. The table below shows where Arabic has to work, and what to check at each one. If a vendor cannot show you every row on a live screen, treat the Arabic support as partial.

Why English-only setups fail at the counter and in the kitchen

The problem is rarely a dramatic failure. It is a steady trickle of small errors. A cashier who reads Arabic best scrolls an English item list and picks the wrong variant. A cook reads an English modifier and misses "no onions". A guest in Iraq, where Arabic-first service is the norm, receives a receipt they cannot easily check against what they ordered. Each of these produces a remake, a discount to calm the guest, or a quiet loss of trust. Other mistakes come from the printer: an Arabic name that prints as disconnected letters on a label looks unprofessional and cannot be read by the person stocking the shelf. A translated menu should also be reviewed for cultural fit, since dish names and ingredients may need different handling in Arabic. The fix is not more translation work for staff. It is a system where each name is entered once, in both languages, and then used everywhere.

Step 1: Enter every name in both languages, once

Arabic-first starts with the data. In Culina, every restaurant name carries an Arabic field: items, modifier groups and options, kitchen stations and floors. On an item, the custom Arabic name field is what prints on labels and on the Arabic receipt. The modifier editor shows English and Arabic inputs side by side, so the person entering "Extra cheese" types "جبنة إضافية" in the next box and moves on. Two habits save trouble later. First, keep the English name stable, because prices and matching stay on the canonical English name, so renaming it casually can confuse reports. Second, have an Arabic speaker from your own team review the Arabic names, rather than relying on machine translation, because a dish name in Baghdad and one in Doha can differ.

Step 2: Set up the Arabic receipt and switch language per user

Culina offers an 80 mm thermal receipt layout and an A4 layout, each with English and Arabic variants. In Settings you choose the receipt Print Format and the receipt width, 80 for thermal or 210 for A4. The Arabic receipt is used automatically when the app is in Arabic, so a cashier who works in Arabic prints Arabic receipts without changing anything else. The ع / EN switch, under More then Language or in the top bar, flips the whole POS, the Kitchen screen and the guest menu between the two languages. This matters in a mixed team: the cashier can work in Arabic, the manager in English, and the cook on the Kitchen screen in whichever he reads fastest, all on the same orders. Printing runs through QZ Tray on each terminal, so set the receipt printer once per machine.

Step 3: Print labels in Image mode and offer the QR menu in Arabic

Labels are where Arabic usually fails. Zebra's built-in fonts do not shape Arabic, so a ZPL label shows the Latin name only. In the QZ Tray printer dialog, set the label format to Image and the label is rasterized and sent as an image, which prints the Arabic name correctly. The trade-off is that Image mode suits normal driver printers, while ZPL is crisp and fast but Latin-only. A Culina label carries the item name, the Arabic name in Image mode, a Code-128 barcode, batch, expiry and profile, one label per unit. On the guest side, the QR menu at /menu and the online ordering page at /order both carry the ع / EN toggle and take their colours and branding from Settings. A guest in Erbil can read the menu in Arabic and a visiting guest can switch to English on their own phone.

Worked example: a Baghdad restaurant

Take a 70-seat grill and rice restaurant in Baghdad, call it Matbakh Al-Karrada. It takes about 400 orders a day across the counter and the dining room. These figures are illustrative assumptions, not benchmarks, so replace them with your own. Before the change, the team works from an English-only item list and English modifiers, and 2% of orders contain a language-related error, such as a wrong variant or a missed modifier. That is 8 orders a day. After moving to Arabic item names, Arabic modifiers and an Arabic kitchen screen, the error rate falls to 0.5%, which is 2 orders a day. Each error costs IQD 6,000 in remade ingredients and the discount given to settle the guest. The figures below exclude tax; confirm the current tax position for your own governorate with your accountant.

That is 180 fewer error orders a month and IQD 1,080,000 saved. The figure is conservative on purpose: it counts only ingredients and goodwill discounts, and leaves out the cashier's training time, the guest's longer wait and the repeat visits that a clear Arabic receipt helps to protect. If your current error rate is already low, the saving will be smaller; if your team is mostly Arabic-reading and the system is English-only, it can be larger. The point of the example is that the case rests on one number you can measure yourself: how many orders were wrong last month because of a misread item or modifier.

What to check before you go live

Test Arabic on the real hardware, not on a demo screen. Print one Arabic receipt on your actual 80 mm printer and read it as a guest would. Print one label in Image mode and one in ZPL, and compare them. Open the QR menu on two different phones, in Arabic and in English. Send an order with a modifier to the Kitchen screen and confirm the modifier appears in Arabic. Then measure for two weeks: the number of remade or corrected orders, and the time a new cashier needs before working alone. If errors do not fall, the cause is usually an Arabic name left blank, which makes the system fall back to English, rather than the idea of Arabic-first itself.

The bottom line

Arabic-first is a data question and a printing question, not a translation question. Enter each name in both languages once, let the receipt follow the active language, print labels as images when you need Arabic on them, and give guests an Arabic QR menu with an English toggle. Culina, a restaurant management system built on ERPNext and used across the GCC and Iraq, provides this in one system: an Arabic field on every item, modifier, station and floor, English and Arabic receipts in 80 mm and A4, Image-mode labels that print the Arabic name, a ع / EN switch across the POS, Kitchen screen and guest menu, and a bilingual QR menu. The same orders feed recipe costing and Menu Engineering, so the data behind your Arabic menu also tells you which dishes earn their place.