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