Translate a PO file (gettext) into Arabic

Six plural forms: the heart of an Arabic PO file

Most languages need two or three msgstr[n] entries per plural string. Arabic needs six, and the header has to declare them. The formula commonly used for Arabic is:

Plural-Forms: nplurals=6; plural=(n==0 ? 0 : n==1 ? 1 : n==2 ? 2 : n%100>=3 && n%100<=10 ? 3 : n%100>=11 ? 4 : 5);

Each index maps to a CLDR category: 0 = zero, 1 = one, 2 = two, 3 = few (3–10, 103–110…), 4 = many (11–99, 111…), 5 = other (100, 101, 102…). For msgid "%d file" / msgid_plural "%d files", forms 3 to 5 look like this:

• msgstr[3] "%d ملفات": plural, for 3 to 10;
• msgstr[4] "%d ملفًا": accusative singular, for 11 to 99;
• msgstr[5] "%d ملف": genitive singular, for 100 and above.

For 1 and 2, Arabic naturally says «ملف واحد» and «ملفان» (the dual) with no digit. gettext tolerates a form that covers a single value of n dropping %d, but Manuce checks every value's variables against the source, so the delivered strings keep the variable. If you prefer the digit-free wording, that is an edit to make on your side.

A common trap: a string built with plain gettext() as "%d file(s)" has a single msgstr and can never be right in Arabic. It needs ngettext() in the code before extraction.

Right-to-left text, punctuation, digits and register

A PO file only holds strings: the interface direction (dir="rtl", mirrored layout) is handled in your application, not in the .po. Several things do change inside the values themselves:

• Arabic punctuation: comma «،», semicolon «؛», question mark «؟». "Are you sure?" becomes «هل أنت متأكد؟».
• Word order: "%s was deleted" becomes «تم حذف %s», with the variable moving to the end. With two variables, positional %1$s and %2$s let them move without breaking formatting.
• Bidirectional text: when %s receives a Latin file name such as "report.pdf", or a string opens with a variable, punctuation may display in the wrong place. Only a screen test with real values shows it.
• Digits: depending on the country, 3 or ٣ is used. Numbers inside strings are not translated; which digits appear is decided by the runtime locale (ar-EG, ar-MA and so on).
• Register: Modern Standard Arabic. Buttons often use the verbal noun rather than the imperative: "Save" becomes «حفظ», "Cancel" becomes «إلغاء». The free sample lets you check this choice.

What Manuce returns, and what it does not do

You get the same file back, ready to drop into locale/ar/LC_MESSAGES/:

• msgid, msgid_plural and msgctxt untouched; only the msgstr values change;
• six msgstr[n] per plural entry, as their number follows the target language;
• a .pot returned as an Arabic .po, with Language: ar and Plural-Forms set in the header;
• #., #: and #, comments preserved, along with entry order, quotes, line endings, encoding and BOM;
• printf variables (%s, %d, %1$s) and tags checked: if an Arabic value keeps diverging, the source value is kept and the report says so;
• left as they are: empty values, URLs, email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable.

What Manuce does not do: it does not compile the .mo, does not change your code or stylesheets for right-to-left display, and does not choose the digit system shown to users. The report lists translated strings and those left unchanged, with the reason.

Preparing the file

• Encoding: the header should read Content-Type: text/plain; charset=UTF-8. Manuce keeps the file's encoding, and a .po declared as ISO-8859-1 cannot hold Arabic letters. Convert it before uploading.
• Fuzzy flags: #, fuzzy flags are preserved, and msgfmt skips fuzzy entries by default. Clear the ones that no longer apply, or translated strings will not show.
• Context: Manuce uses msgctxt and #. comments to guide the translation. "Open" as a menu action and "Open" as a status translate differently in Arabic («فتح» versus «مفتوح»); a msgctxt is enough to separate them.
• Names to keep: for a product name that must stay in Latin script, check how it is handled in the free sample, then in the delivered file.

Checking the Arabic .po after delivery

• Compile with msgfmt -c --statistics ar.po -o ar.mo: -c checks the header, format strings and plural consistency.
• Test a plural string with n = 0, 1, 2, 5, 11 and 100 to hit all six indices.
• Open the screens where a Latin variable sits inside Arabic text, and those where a string begins with a variable.
• Read the report: a value left in the source language often points to a misplaced variable in the original msgid.

Arabic carries a ×1.6 coefficient on the per-word price, applied only to the words in the values, with keys and tags excluded.

In practice

1. Make sure the header declares charset=UTF-8 and clear fuzzy flags that no longer apply.
2. Upload the .po or .pot: the quote appears at once, based on the words to translate.
3. Read the free Arabic sample to judge register and terms, then pay.
4. Download the Arabic .po and the report, and compile it with msgfmt -c.
5. Test the interface with n = 0, 1, 2, 5, 11 and 100 and Latin-script variables.