Skip to content

feat(works): add the Qurʾān with a sura-verse citation system - #32

Draft
maehr wants to merge 1 commit into
mainfrom
feat/quran
Draft

feat(works): add the Qurʾān with a sura-verse citation system#32
maehr wants to merge 1 commit into
mainfrom
feat/quran

Conversation

@maehr

@maehr maehr commented Aug 25, 2026

Copy link
Copy Markdown
Member

Refs #23

Draft: does not compile. Blocked on textrefs/textrefs.org#94. See "The blocker" below.

What this adds

systems/quran-sura-verse.yaml and works/quran.yaml. 114 suras, 6,236 verses, in the Kufan counting the 1924 Cairo edition fixed.

The verse counts

Taken from the Tanzil Quran metadata XML (https://tanzil.net/res/text/metadata/quran-data.xml, CC BY), not from memory. Parsed, and checked: 114 entries, indices 1–114 with no gap, sum 6,236. They live under references_range.counts, which is where they do real work — they bound the minted reference set.

The resolver — Corpus Coranicum /print

#23 proposed the /commentary view and flagged three caveats. /print is the better target, and it answers one of them.

Checked in a browser on 2026-08-25, sampled across the whole text:

Requested Rendered
1:1 Druckausgabe Sure 1 Vers 1
2:255 Druckausgabe Sure 2 Vers 255
18:10 Druckausgabe Sure 18 Vers 10
55:13 Druckausgabe Sure 55 Vers 13
78:1 Druckausgabe Sure 78 Vers 1
112:1 Druckausgabe Sure 112 Vers 1
114:6 Druckausgabe Sure 114 Vers 6
999:999 Error 404. The requested resource could not be found
2:9999 Error 404. The requested resource could not be found

/print rejects an out-of-range verse. /commentary does not. #23 reported sura/999/verse/999/commentary rendering a page, and rated it the same risk class as the Scaife fallback. The print view does not have that problem, so it is the safer resolver as well as the better-covered one.

Each valid page names its edition: the Cairo 1924 print (Ägyptisches Katasteramt, Gizeh) — the same edition that fixed the counting the citation system uses.

One caveat from #23 stands: routing is entirely client-side and the server returns byte-identical HTML for every path, so no automated link check can ever validate one of these URLs. That is recorded in a comment on the resolver.

Licence

No license:. The BBAW imprint contains, in one paragraph, both "Alle Rechte vorbehalten" and "Lizensiert unter einer Creative Commons Namensnennung 3.0 Lizenz". That contradiction is not an SPDX identifier, so this records license_url: only and points at the imprint — the BHS precedent from #19.

Two corrections to #23

  1. chapter_sizes: is omitted. It gates one thing only, the {verseGlobal} template variable, and only for systems whose capture groups are named exactly chapter and verse (compile.ts:168-184). This system names them sura and verse, so the field would be inert.
  2. chapter_sizes: does not reject an out-of-range verse. data: add the Qurʾān as a work with a sura-verse citation system #23 says it "lets the compiler reject an out-of-range verse rather than minting 2:999". It does not — compile.ts:168-184 adds the verse to the offset without ever comparing it to chapter_sizes[ch-1]. Only an out-of-range chapter is caught, and then only by dropping the resolver target with a warning. Verse-count correctness is entirely on the author.

The blocker

The separator. 2:255 is how the Qurʾān is cited; every other system here uses a dot. expandRange hardcodes . for every multi-part range kind (compile.ts:68-74), while the system's own locator_regex is the real definition of the canonical form. npm run compile:data:

Error: quran-sura-verse: locator "1.1" does not match locator_regex
    at assertValidLocator (/…/scripts/compile.ts:191:9)
    at emitBlockReferences (/…/scripts/compile.ts:366:3)

Filed as textrefs/textrefs.org#94, with a proposed separator field defaulting to . so no existing locator moves. This branch is the reproduction.

Three ways out, in preference order:

  1. Land the separator field upstream, then this merges unchanged.
  2. Spell the Qurʾān 2.255. No code change, consistent with the registry, but not how anyone cites it — and changing it later re-mints all 6,236 reference UUIDs (cheap now while everything is draft, expensive after promotion to active).
  3. List all 6,236 locators under references:. Legal, but it puts a generated table in a hand-authored file.

Other checks

  • Wikidata Q428 verified: labels.en.value = "Qur’an", described as the foundational Islamic religious text. Not an edition, translation or disambiguation page.
  • locator_regex tested with the u flag, which is how src/lib/find.ts:159 recompiles it: 1:1, 2:255, 114:6, 100:1 accepted; 115:1, 0:1, 2:0, 2/255, 2.255, 1:1a rejected.

Add `systems/quran-sura-verse.yaml` and `works/quran.yaml`. The Qurʾān is the
most obvious remaining gap in the scriptural set, and sura-and-verse is the
strongest citation system in the corpus survey: stable, universal,
edition-independent, and closed at 114 suras and 6,236 verses.

The verse counts come from the Tanzil Quran metadata XML, not from memory. The
resolver is the Corpus Coranicum `/print` view, checked in a browser on
2026-08-25 across seven suras spread over the whole text, with two out-of-range
controls that both render a 404 message. `/print` rejects a bad verse;
`/commentary` does not, which is why this uses `/print`.

The system omits `chapter_sizes:`. It gates only `{verseGlobal}`, and only for
capture groups named `chapter` and `verse`. Here they are `sura` and `verse`,
so the field would be inert.

DOES NOT COMPILE YET, deliberately. `npm run compile:data` fails with:

    Error: quran-sura-verse: locator "1.1" does not match locator_regex
        at assertValidLocator (scripts/compile.ts:191:9)
        at emitBlockReferences (scripts/compile.ts:366:3)

`expandRange` hardcodes `.` as the separator for every multi-part range kind,
while the system's `locator_regex` is the real definition of the canonical
form. The Qurʾān is cited `2:255`. Blocked on the parent-repo issue that
tracks this.

Refs #23

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CD9MxbT2jSZmJyR9ywJGEs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant