Follow the writing rules in the README and two messages

Remove "should" from the README and the semicolons from two messages.
Correct the note about a local run without CWA.
This commit is contained in:
tim
2026-10-02 23:37:33 +02:00
parent 9c9c5b7dac
commit c0504135b2
3 changed files with 5 additions and 7 deletions
+3 -5
View File
@@ -164,7 +164,7 @@ hash, it uses the OPDS login.
`CWA_DB_PATH` is the path of `app.db` inside the container. To use it, mount the CWA config folder
read-only into the container. Mount the whole folder, so that SQLite can read the journal files
beside the database. **Bindery does not write this database**, and access should ideally be read-only.
beside the database. **Bindery does not write this database.**
**Database logins check only the password.** CWA's external login providers and multi-factor
authentication do not apply. If they must apply, use the `proxy` mode.
@@ -280,8 +280,7 @@ set `CALIBRE_DB_PATH`, then through CWA. If you deleted the book in CWA, Bindery
`CALIBRE_DB_PATH` is optional. It is the path of the calibre `metadata.db` inside the container, and
it lets Bindery find a book by its story URL instead of its title. To use it, mount the library
folder read-only into the container. Mount the whole folder, so that SQLite can read the journal
files beside the database. The Compose file has an example. **Bindery does not write to this database**,
and access should ideally be read-only.
files beside the database. The Compose file has an example. **Bindery does not write to this database.**
Be sure to use the library that gets the ingest files. A different library can make Bindery update the
wrong book. Database lookups also find books that the CWA account of Bindery cannot see. If Bindery
@@ -524,8 +523,7 @@ the pages in a browser.
### Run locally without CWA
Without CWA, Bindery puts the first download of each story into its ingest folder as an ePub. Later
downloads fail, because Bindery needs CWA to find the book, but their chapters stay stored. This is
Without CWA, Bindery puts each new build of a story into its ingest folder as an ePub. This is
enough to work on downloads, chapters, rules and the web interface.
```bash
+1 -1
View File
@@ -148,7 +148,7 @@ def check_personal_ini(text: str) -> list[str]:
try:
configuration.read_file(io.StringIO(text))
except configparser.ParsingError as e:
lines = "; ".join(f"line {n}: {line.strip()}" for n, line in e.errors)
lines = ", ".join(f"line {n}: {line.strip()}" for n, line in e.errors)
raise ValueError(f"FanFicFare cannot read this personal.ini. Check {lines}") from e
except configparser.Error as e:
raise ValueError(f"FanFicFare cannot read this personal.ini: {e}") from e
+1 -1
View File
@@ -1259,7 +1259,7 @@ def _run_site_job(job: Job) -> str:
if mode in (DownloadMode.RECHECK_ALL, DownloadMode.FULL):
store.set_setting(story_id, "last_full_recheck", now())
if not store.chapters_for_build(story_id):
raise StoryError("; ".join(summary) + ". No chapters downloaded.")
raise StoryError(", ".join(summary) + ". No chapters downloaded.")
# The book is built and sent only when its chapters, rules or metadata changed. A job that resumes, or that
# follows a failed job, finds the changes of the earlier run through the key.