Skip to main content

Localization

One request, one key — language follows the header.

How It Works​

Send an Accept-Language header with each request. The API returns the same JSON structure with localized text fields reflecting your language choice. There are no name_ar / name_en split keys in the response — the name key always appears, and its value is in the requested language.

Header valueLanguage returned
Accept-Language: en (default)English
Accept-Language: arArabic

If the header is omitted or set to an unsupported locale, the API falls back to English.

Localized Fields by Resource​

ResourceLocalized fields
Recitationname, description
Recitername, bio
Riwayahname, bio
Qiraahname
Publishername

Related resource embeds (publisher.name, reciter.name, etc.) inside a recitation response are also localized — you get Arabic names throughout the payload with a single header.

Example​

The same /reciters/ endpoint with two different Accept-Language values:

# English (default)
curl -H "Accept-Language: en" https://staging.api.cms.itqan.dev/reciters/

# Arabic
curl -H "Accept-Language: ar" https://staging.api.cms.itqan.dev/reciters/

English response:

{
"count": 42,
"results": [
{ "id": 1, "name": "Mishary Rashid Alafasy", "bio": "...", "recitations_count": 5 }
]
}

Arabic response:

{
"count": 42,
"results": [
{ "id": 1, "name": "مشاري راشد العفاسي", "bio": "...", "recitations_count": 5 }
]
}

Same id, same structure — only the text values differ.


See also: Design Principles · Related Object Embeds · Error Handling