// Parse JW.org NWT EPUBs to extract individual Bible verses for verse previews, parallel-corpus building, and Bible-coverage analytics. Use when working with NWT EPUB files, building parallel Chuukese↔English Bible data, or wiring scripture preview features.
| name | bible-epub-processing |
| description | Parse JW.org NWT EPUBs to extract individual Bible verses for verse previews, parallel-corpus building, and Bible-coverage analytics. Use when working with NWT EPUB files, building parallel Chuukese↔English Bible data, or wiring scripture preview features. |
JW.org publishes the New World Translation as EPUB. We parse it on demand to fetch individual verses (for preview popups and coverage analytics), and bulk-extract for building parallel training data.
src/utils/nwt_epub_parser.py — minimal, intentional surface:
from src.utils.nwt_epub_parser import NWTEpubParser
parser = NWTEpubParser("config/data/bible/nwt_chk.epub")
text = parser.get_verse(book_num="40", chapter=1, verse=1)
# → "Chón anūn... Jesus Kraist..." or None if not found
That's it. There is no get_book_list(), get_chapters(), get_verses(), or ParallelCorpusBuilder class — older skill docs invented those. The full implementation:
__init__ loads the EPUB and calls _build_chapter_map()._build_chapter_map() reads toc.xhtml and per-book biblechapternav<N>.xhtml files to map {book_num_str: {"name": str, "chapters": {chapter_int: chapter_file}}}.get_verse(book_num, chapter, verse) opens the chapter XHTML, finds the element with id chapter{N}_verse{M}, and returns its text.Book numbers are strings keyed "1" through "66". Pass "40" for Matthew, not 40.
config/data/bible/ — typically nwt_chk.epub (Chuukese) and nwt_en.epub (English). Not under a top-level data/ directory.config/bible_books.json.(book, chapter, verse)): config/scripture_books.json + src/utils/scripture_parser.py. See the scripture-reference-parsing skill.The parsers are lazily initialized — they're slow to construct (~1–2s per EPUB) so the app holds a singleton:
GET /api/scripture/preview?ref=... (app.py) — returns CHK + EN side-by-side.GET /api/bible/coverage (app.py) — summarises which verses appear how often across the corpus.Anti-scrape robots policy on Bible endpoints: app.py. When you add a new Bible-related endpoint, route it through the same gate.
The "parallel corpus" is built ad-hoc by iterating book/chapter/verse triples and calling get_verse on both EPUBs. There is no class for it; the recipe lives in scripts/extract_brochure_sentences.py (for brochures) and analogous in-line code under scripts/. If you need a reusable parallel builder, write it new — just don't put it on NWTEpubParser itself, keep the parser's public API tiny.
from src.utils.nwt_epub_parser import NWTEpubParser
chk = NWTEpubParser("config/data/bible/nwt_chk.epub")
en = NWTEpubParser("config/data/bible/nwt_en.epub")
pairs = []
for book_num, book in chk.book_chapter_map.items():
for ch_num in book["chapters"]:
for v_num in range(1, 200): # verses are sparse; break on None
ch = chk.get_verse(book_num, ch_num, v_num)
if ch is None: break
en_text = en.get_verse(book_num, ch_num, v_num)
if en_text:
pairs.append({"chk": ch, "en": en_text, "ref": f"{book['name']} {ch_num}:{v_num}"})
Feed pairs into AITrainingDataGenerator.export_training_data(...) for the standard jsonl/huggingface/ollama outputs.
get_verse returns None when the verse doesn't exist (end of chapter, missing book). Always handle None — don't assume continuous numbering.id="v{N}" instead of id="chapter{N}_verse{M}" — the parser will silently return None for those. If extraction is empty, dump the chapter HTML and check the id format.app.py; never NWTEpubParser(...) per request.href.startswith("biblechapternav")) is brittle — JW.org occasionally changes filenames. If a new EPUB build breaks parsing, inspect book.get_items() filenames first.*, +). Strip them before training data generation; preview UI keeps them.Generate high-quality training datasets from documents, text corpora, EPUBs, and structured content. Use when creating AI training data from dictionaries, Bible EPUBs, brochures, or when generating examples for machine learning models. Optimized for low-resource languages and domain-specific knowledge extraction. Supports parallel corpus extraction from NWT Bible EPUBs.
Deploy the Chuuk Dictionary stack (main app + Ollama sidecar) to Azure Container Apps. Covers ACR remote builds via `az acr build`, Key Vault prerequisites, Cosmos DB credential injection, and the env-var contract. Use when running a deploy, debugging a failed deploy, or modifying Azure infrastructure.
Specialized processing for Chuukese language text including tokenization, accent handling, cultural context preservation, and language-specific patterns. Use when working with Chuukese text, translation tasks, or when building language models for this Micronesian language.
Comprehensive code documentation standards and guidelines for maintaining up-to-date documentation across Python, HTML, CSS, and JavaScript codebases. Use when creating or modifying code to ensure proper documentation practices and maintainable code.
Styling conventions for the Chuuk Dictionary frontend — Mantine v8 theme, CSS Modules per page, global app-shell CSS, multilingual / accented-character considerations. Use when adding or modifying styles in `frontend/src/`.
Conventions for the Chuuk Dictionary persistence layer — Azure Cosmos DB (MongoDB API) via `db_factory`, `DictionaryDB`, `UserDB`, and `PublicationManager`. Covers connection-resolution order, the actual collection/method names in use, and the managed-identity path. Use when adding queries, debugging connection issues, or extending the schema.