Short answer. A two-language application is decided in week one, not at the end. You first write where each language goes: the interface in Arabic and French, WhatsApp messages in darija written in Latin letters, bilingual documents. Then you build five things. Texts: one key per sentence, named variables, and Arabic’s six plural forms where French has two; never a sentence assembled from pieces. Layout: written in start and end, never left and right, so that it mirrors on its own; a list of what mirrors, arrows and lists, and what does not, clocks and digits. Data: the Algerian Arabic locale writes the same digits as French, with a comma decimal; dates follow the locale; database and API always stay in Western digits. Inserted values, names and numbers, are isolated so that the + of +213 does not jump sides. And review by someone who reads Arabic, on the phone, at every demo. Six weeks, and the Arabic version is visible from the third.
This guide is for the manager whose employees read Arabic and whose suppliers read French, the founder settled in France who speaks to customers in darija on WhatsApp and to the bank in French, and the person who must compare one “bilingual” quote with another. It does not repeat how search understands Arabic and darija, described in the search guide, nor how an agent speaks on WhatsApp, described in the dedicated guide; it describes what is built so that the interface, messages and documents are right in both languages, and extends our page on mobile applications.
What the references say
The locale has a public definition, and it often surprises. The Unicode locale data repository, the one phones and browsers follow, gives Arabic for Algeria a default numbering system of “latn”, that is the digits 0 to 9 you are reading here, not the so-called Eastern Arabic digits used in the Mashreq; it gives the comma as decimal separator and the dot as thousands separator, so that twelve thousand four hundred dinars is written “12.400,00” in Algerian Arabic. What this imposes: an app set to generic “Arabic” will show digits your employees do not read every day; the locale must be Arabic for Algeria, and the digits the same in both languages.
The mirroring layout has rules written by the platforms. Android’s documentation asks to declare that the app supports right-to-left, to replace “left” and “right” everywhere with “start” and “end”, and warns that icons to mirror are declared one by one, because “if reflecting your drawable changes its interpretation”, it must not be reflected: a clock, a player, a logo do not mirror. It also describes the trap of inserted values: a number starting with “+” or an address starting with a digit, placed in an Arabic sentence, see their beginning jump to the other side, and the fix is to wrap each inserted value in direction marks. What this imposes: the list of what mirrors is written in week one, and every variable of a sentence is isolated before entering it.
The same documentation flags an invisible trap: formatting a number with the device locale to put it in a query or an address produces, on a phone set to Mashreq Arabic, digits the database does not understand; what a machine reads is always formatted in Western digits. And since Android 13, the user can choose each app’s language independently of the phone’s, which matters for a company where the till is in Arabic and accounting in French on the same device. What we did not find: a public study of the languages preferred by business-app users in Algeria; what we see on our projects is Arabic at the counter and in the warehouse, French in the offices and documents, and darija in messages, and we say so as an observation.
The same screen, in French and Arabic
The Arabic version is not understood on a principle but on a screen, drawn twice.
What mirrors. The back arrow points right, because “going back” in Arabic is to the right. List labels move to the “start” side, which is the right, and amounts to the “end” side, which is the left. The progress bar fills from the right. All of this happens on its own if the layout was written in start and end; nothing happens, or everything mirrors including what should not, if it was written in left and right and “adapted” afterwards.
What does not mirror. The clock, because a mirrored clock is wrong. The digits, because the Algerian Arabic locale uses the same ones as French: 11.760,00 in Arabic, 11 760,00 in French, the difference is in the separators, not the digits. The phone number, isolated so that “+213” stays at the start and digit groups keep their order. The date, 10/11/2026, identical in both languages because the locale says so. And the logo. The list of what mirrors and what does not fits on a page, and it is written in week one, before the first mock-up.
«The Algerian Arabic locale writes the same digits as French; what changes is the separators, the direction of the page, and the order of words.»
An application in two languages, in five layers
Behind that screen, five layers, and the one where the Arabic version is won or lost.
Texts and translations: one key per sentence, named variables, each language’s plurals, and three files, French, Arabic, and darija for messages; no sentence built from pieces in the code, no hard-coded text. Layout: everything written in start and end; navigation arrows and lists mirror, clocks, players and digits do not; icons that reflect are declared one by one; a single mock-up, tested in both directions from week one. Data: digits, dates, currency and sorting per locale; search that understands Arabic without diacritics and both spellings of a name, per the search guide; what the database and API store never changes language.
Input: Arabic and French keyboards, phone normalised to +213 however it was typed, names stored in both scripts when needed, addresses and wilayas in two languages; a customer entered in Arabic at the counter must be found in French from France, which is the rule the data migration guide applies to old files. Process: every screen reviewed by someone who reads Arabic, screenshots in both directions in acceptance, and texts delivered to the translator with their context; the Arabic version is not “the translation at the end”, it is delivered at every demo, per the delivery guide.
Six traps of a two-language application
Six traps we find on almost every Arabic version we take over, and what gets built against each.
The sentence built from pieces: “Order” + n + “delivered” works in French and gives in Arabic a wrong word order and a wrong plural; one key per sentence, and Arabic’s six plural forms in the language file. The broken phone number: +213 661 23 45 67 inside an Arabic sentence sees its + and groups change places; every inserted value is isolated before entering. Everything mirrors, or nothing: either buttons and the clock are backwards, or nothing mirrors and Arabic is left-aligned; layout in start and end, and a written list of what mirrors.
Digits that change: amounts in Eastern Arabic digits, or dot and comma swapped between languages; Algerian Arabic locale, Western digits, comma decimal, dot thousands, and the database always in Western digits. The ambiguous date: 03/11 read “3 November” by one and “11 March” by the other, and Mashreq month names nobody reads in Sétif; format per locale, months spelled out in documents, Algerian month names in Arabic. The font without Arabic: boxes instead of letters on a 2019 Android, or an Arabic font that clashes with the French one; a family covering both scripts, embedded in the app and the PDFs, tested on the old phone the speed guide already requires.
One sentence, from translation key to the customer’s phone
A sentence crosses six stages before reaching a phone, and each is a rule, not a gesture.
The key: a sentence is a key, order.delivered, with named variables, the count, the name, the date; never a concatenation. The three files: French, Arabic, and darija for WhatsApp messages; the Arabic file carries the six plural forms, zero, one, two, few, many, other, because “3 parcels” and “11 parcels” are not said with the same form, and “2 parcels” has its own, the dual. The plural rule is applied by the language, not by the developer: for three, French picks its “other” form and Arabic its “few” form.
Formatting by locale: Western digits, comma decimal, dot thousands in Algerian Arabic, date in local format, and never “11/10” for 10 November. Isolation: name and number are wrapped before entering the sentence, otherwise the + and digits jump sides in an Arabic sentence. Rendering in three registers: “3 parcels delivered to Karim Benali on 10/11/2026” for the manager, the same in Arabic for the employee, and “3 colis wslou l Karim” in darija for the customer, written in Latin letters because that is how your customers write it, through the templates described in the notifications guide.
«A sentence is a key with variables, translated three times, pluralised by the language, formatted by the locale, and isolated where a value enters.»
Seen elsewhere: locale and platform references, and what transposes
Two sources say the essentials. The Unicode locale repository says Algerian Arabic is written with Western digits, a comma decimal and a dot thousands separator; what transposes is that the locale is ar-DZ, not “Arabic”, and that digits are the same in both languages of the app. Android’s documentation says to write layout in start and end, to declare icons to reflect one by one, to isolate values inserted into sentences, and never to format with the locale what a machine will read; what transposes is the list of what mirrors, systematic isolation of variables, and the separation between what the user sees and what the database stores.
What these sources do not say: which language your employees read at the counter, which language your customers write on WhatsApp, and which documents must be bilingual; the project’s first week answers that, and the manager signs the list.
Delivering the Arabic version, in six steps
The Arabic version is not a translation added on: it is a six-step path that starts before the first mock-up.
Decide where each language goes: interface in Arabic and French, messages in darija, bilingual documents; written and signed. Extract texts into keys: named variables, plurals, and context for the translator; not one hard-coded text remains. Mock up in both directions: start and end, the list of what mirrors, fonts with both scripts; it is the step that costs an hour in week one and weeks if skipped.
Translate with context: one screenshot per screen, so that the translator sees where the sentence goes and picks the right word. Review on the phone: by someone who reads Arabic, with screenshots in both directions in acceptance; it is the step always skipped, which is why the buttons are backwards. Deliver at every demo: both languages together, never French first and Arabic “later”, when nobody has time any more.
The rules of an application that works in both languages
Six rules, written in week one. Where each language goes is written: interface, messages, documents. One key per sentence, named variables, each language’s plurals. Layout in start and end, and the list of what mirrors. The Algerian Arabic locale for digits and dates; the database in Western digits. Every inserted value is isolated. The Arabic version is reviewed on the phone by someone who reads Arabic, at every demo.
A seventh rule concerns the quote: “bilingual Arabic-French application” is not a requirement, it is a sentence; the requirement reads “languages per use written: interface, messages, documents; texts in keys with named variables and plurals per language, no hard-coded text; layout in start and end with list of reflected elements; ar-DZ locale for digits, dates, currency, sorting; bidi isolation of inserted values; fonts covering both scripts in the app and PDFs; review by an Arabic reader and screenshots in both directions at every acceptance; WhatsApp messages in darija”, and it is checked as the specification guide recommends. A quote that writes “Arabic translation included” plans to translate at the end, and that is the version with the buttons backwards.
Six applications, and their language question
Six applications we often build, and for each the language decision that mattered most.
- The in-store point of sale, described in the dedicated guide. Interface in Arabic for sales staff, bilingual receipts, identical digits in both languages; the total is the same whichever side the customer reads.
- The B2B ordering portal, described in the dedicated guide. Retailers order in Arabic, the wholesaler reads in French; product names are stored in both scripts and search understands both.
- The shop run from France, described in the dedicated guide. The founder reads the dashboard in French, the team in Algiers works in Arabic; same app, same data, language per user.
- The tutoring platform, described in the dedicated guide. The parent in France receives messages in French, the pupil in Algeria works in Arabic, and the WhatsApp reminder goes out in darija.
- The Umrah agency, described in the dedicated guide. Pilgrims’ documents are bilingual, with dates spelled out in both calendars, because an ambiguous date on a visa is not an option.
- The updated mobile app, described in the dedicated guide. A new text ships through the language files served by the API, without going through the stores, in all three registers at once.
The 2027 calendar
The calendar is that of an application delivered in both languages in six weeks, with the Arabic version visible from the third.
Week 0 to 1 writes languages and rules: which language for the interface, messages and documents; digits, dates and currency per the Algerian Arabic locale; the list of what mirrors and what does not; signed by the manager. Week 1 to 2 extracts texts into keys, with named variables, plurals and context; not one hard-coded text remains in the code. Week 2 to 3 writes the layout in start and end, declares icons to reflect, embeds fonts with both scripts, and shows the first screen in Arabic: that is the week the Arabic version becomes real.
Week 3 to 4 handles data and input: formats per locale, Arabic sorting and search, normalised phone, names in both scripts. Week 4 to 5 is the review: every screen reread on the phone by an Arabic reader, screenshots in both directions in acceptance, fixes. Week 5 to 6 delivers bilingual PDF documents with both scripts and WhatsApp templates in darija, and goes to production. Every batch is demoed in both languages, as the delivery guide describes: the Arabic version is never “later”.
What makes a two-language application fail
The Arabic versions we take over almost always failed for one of these reasons.
- Translated at the end. The layout is in left and right, and mirroring it costs weeks; it ships “without the mirror”.
- Sentences assembled from pieces. Arabic word order is wrong, and nobody read it.
- Generic Arabic. Eastern digits employees do not read, Mashreq month names.
- Values not isolated. The + of numbers and the digits of addresses jump sides.
- Everything mirrored. The clock, the player and the logo too; the app looks broken.
- A font without Arabic. Boxes on 2019 phones, which the developer does not have.
- Nobody on the team reads Arabic. The version ships without a single screen reviewed.
Frequently asked questions
The questions we receive from managers, founders and IT managers.
- Why does the Arabic version of our app have the buttons backwards?
- Because the layout was written in left and right, then translated and “mirrored” at the end. A layout written in start and end mirrors on its own and cleanly; and a written list of what mirrors, arrows and lists, and what does not, clocks, digits and logos, prevents everything or nothing being mirrored. This is decided in week one, before the first mock-up.
- Should digits be Arabic digits in the Arabic version?
- In Algeria, no: the Algerian Arabic locale in the Unicode repository uses Western digits, 0 to 9, with a comma decimal and a dot thousands separator. An app set to generic “Arabic” would show the so-called Eastern digits, which your employees do not read every day. Digits are therefore the same in both languages; only the separators change.
- Why are phone numbers cut in Arabic messages?
- Because a number starting with “+”, inserted in a right-to-left sentence, sees its beginning and digit groups change places: the text does not know where the number starts. The fix is to wrap every inserted value, number, name, address, in direction marks before placing it in the sentence, systematically, in the code that renders texts.
- How is darija handled?
- As a third language, for messages only: WhatsApp and SMS templates have a darija version written in Latin letters, because that is how your customers write it, with the same variables and isolation as the others. The interface stays in Arabic and French; search, for its part, understands all three, as the search guide describes.
- Does everything have to be translated twice at every change?
- Every new sentence is a key added to the three language files, with its context for the translator, and it ships through the API without going through the stores. A version that adds ten sentences adds ten keys; the translator sees them with a screenshot of the screen they go to, and an Arabic reader reviews the screen before the demo. It is the same rhythm as the rest of delivery.
- How long for an application in both languages?
- Six weeks when both languages are decided at the start: one for languages and rules, one for texts into keys, one for layout in both directions, one for data and input, one for review, one for documents and messages. Adding Arabic to an app built in French only costs more than those six weeks, because the layout has to be rewritten.