Validating Arabic text in forms: names, free text and the traps

Most guides to validating form input are written for English. Their examples assume Latin letters, and when you carry them over to Arabic they behave in ways nobody warned you about. A pattern that you believe accepts "Arabic letters only" may let digits through. A rule that accepts a single word may refuse "Abd Allah". This article goes through what actually happens, so that your Arabic fields accept what they should.

What you may want to say

• "This field must be in Arabic." (A name on an official form, a field filled in for a ministry.)
• "This field must be in English." (A name that has to match a passport.)
• "Either is fine." (A mixed audience.)
• "Only digits." (A phone number or an ID. See the separate article on phone numbers.)

The ready-made format: Arabic letters only

The Pattern helper has a format called Arabic letters only. It is written ^[ء-ي ]+$ and it accepts the letters from hamza (ء) to ya (ي) and spaces. We tried it on typical answers:

It also has an English letters only format, ^[A-Za-z ]+$, for names that must be written in Latin letters.

Two of those results are decisions you should make on purpose:

• Diacritics are refused. If someone types a name with the short-vowel marks, the answer fails. For names that is usually what you want, as people rarely type the marks; for a field where marks are normal, write your own pattern.
• Persian and Urdu letters are refused. The range covers the Arabic alphabet only. If some of your respondents write in those languages, this format will turn them away.

The trap: writing it yourself with \p{Arabic}

A common shortcut is ^\p{Arabic}+$, meaning "anything in the Arabic script". It looks right, and it is looser than it sounds. We tried it:

So it refuses a name of two words, because a space is not an Arabic letter, and it accepts digits, which is rarely what "Arabic letters only" is meant to mean. For a name field, use the ready-made format.

Mixed Arabic and English

There is no ready-made "either" format. If both are fine, write your own pattern in the box, for example ^[ء-ي A-Za-z]+$, which accepts Arabic letters, Latin letters and spaces. Try it with Try a value, with the real names your respondents will write, before you publish. Note that it also accepts a mix inside one answer, such as "Sara سارة".

Should you restrict names at all?

Often, no. Names contain apostrophes, hyphens and letters from other alphabets, and a strict rule turns away real people with the message that they typed their own name wrongly. A pattern earns its place when something downstream depends on the shape: a registry that only accepts Arabic names, a certificate printed in Arabic. When nothing does, a length rule is kinder: a minimum of two characters stops a single letter, a maximum keeps the field short.

The variants you cannot validate

Arabic spelling has pairs that look alike and are typed interchangeably: ي and ى, ة and ه, the different forms of alef (ا أ إ آ). A pattern accepts all of them, since they are all letters, so validation will not unify them. If you plan to count or match answers later, such as how many people wrote a given city, offer a list of choices instead of free text, so that everyone picks the same spelling.

Where it is enforced

The pattern is checked on the public link, on the in-app fill page and when you import a CSV file. It is not checked in the Collect app, because an offline phone cannot judge patterns reliably. A collector's answer is always kept and, if it does not fit, marked for you to review.

In Pulseform

See building a form and its field rules for the pattern box and the Pattern helper, and the wider picture in form data validation. If you only need the pattern, the free pattern builder writes it for you.