Translate a CSV string table into Arabic

What Arabic changes in a string table

A CSV stores text in logical order, the order in which it is typed. Arabic runs right to left and its letters join, each one taking a different shape depending on its position in the word. The file therefore holds base characters, and it is your application's text renderer that joins them and aligns them to the right. Open an Arabic CSV in a plain text editor and a row mixing a Latin key, delimiters and Arabic text can look scrambled: the file is fine, and editing it by hand to 'fix' the order will break it.

• Punctuation: Arabic has its own comma ،, semicolon ؛ and question mark ؟. They are different characters from the CSV delimiter. Welcome, {player}! becomes, for instance, مرحبًا، {player}!.
• Placeholders inside right-to-left text: {0}, %d or {player} stay in Latin characters within the Arabic sentence. Their position often moves (Level {0} → المستوى {0}), and on screen they can appear to jump when they sit next to punctuation.
• Addressing the user: Arabic imperatives agree with the reader's gender. Interfaces usually prefer the neutral verbal noun, so 'Save' becomes حفظ ('saving') rather than an imperative.
• Digits: the Maghreb uses 0-9, while the Levant, Egypt and the Gulf often use Eastern Arabic digits ٠١٢٣. That is a formatting setting in your app, not something the string table decides.

Six plural forms, one row per form

A CSV has no plural structure: each form is a separate row, told apart by its key, for example files_count_one and files_count_other for an English source. Arabic needs six (zero, one, two, few, many, other), and the noun genuinely changes:

• zero: لا توجد ملفات (no files)
• one: ملف واحد
• two: ملفان (the dual, no number needed)
• few (3 to 10): {0} ملفات
• many (11 to 99): {0} ملفًا
• other (100, 1000…): {0} ملف

Manuce translates the values of the rows that exist and does not add keys. If your table only has _one and _other, the Arabic column will hold two translations, and a counter at 11 will show the 'other' form, which is grammatically wrong. To get it right, add the missing rows before uploading, with the source text copied in and a note in the context column ('plural, 3 to 10'), then make sure your engine can select between all six categories.

What Manuce returns, and what it does not do

Manuce recognises a developer CSV by its key column (key, id…) followed by language columns (en, fr, de_DE…), the layout used by Unity or Godot.

• If an ar column exists, it is filled in; otherwise it is added as the last column.
• A comment or context column is read as context: that is where you say a string is a button, a heading or a counter.
• Everything else stays as it was: key order, quoting, comments, line endings, encoding and BOM. Only the values change.
• Every Arabic value is checked against the source: if {player} or a <b> tag is missing or altered and the mismatch persists, the source value is kept and the report says so.
• Not translated: keys, empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable.

You get the same file back, ready to re-import, plus a report listing the strings translated and those left as they were, with the reason. Manuce does not create plural keys and does not configure right-to-left layout or fonts in your app. A CSV without a key column is not treated as a language file: it is translated as plain text.

Preparing the file and checking the result

1. Encoding: Arabic needs a Unicode encoding. A CSV saved as Windows-1252 or Latin-1 cannot hold Arabic letters, so save it as UTF-8 before uploading. Because encoding and BOM are preserved, your source file decides. A spreadsheet may show UTF-8 without a BOM as gibberish even though the file is correct, so judge the result in your engine instead.
2. Column header: if your engine expects ar, ar_SA or ar_EG, create the empty column with that name and it will be filled under that header.
3. Context: fill in the context column for short, ambiguous strings ('Open': verb or state? 'Back': return or the back of something?) and for gender when a line addresses a specific character or player.
4. Terms to keep: a game or product name that must stay in Latin script is something to check in the free sample, then in the delivered file.
5. Test in the engine: import the table and go through a few screens. Check that letters join, text is right-aligned, the font includes Arabic glyphs, and diacritics (the ً in مرحبًا) are not clipped at the top or bottom of text boxes.

In practice

1. Save the CSV as UTF-8 and make sure it has a key column (key, id…).
2. If needed, add the Arabic column under the header your engine expects (ar, ar_SA…) and fill in the context column, plural rows included.
3. Upload the file: instant quote on the words in the values, free sample before you pay.
4. Download the file and the report, then deal with any strings left in the source language.
5. Import the table and test the display: joined letters, right alignment, font, plurals.