Okay, that sounds good, let me think through the logic of it. We could implement an “exceptions” field instead of
When fully published:
Now, if there is incremental publishing, we might have:
The logic for pushing files to
published would then be:
Then check what files exist in project.
For existing files:
If file is empty, leave as
Else if file has content, check whether it is in
If it is in
exceptions, leave as
if it is not in
exceptions, promote to
There would also have to be additional logic at the Bilara side in order to populate the exceptions field:
is_ready_for_publication: true AND not
Then display publish button on texts in project.
For texts in project:
If no translation strings have been entered, do nothing.
If translation strings have been entered AND publish has not been pressed, add text ID to
If translation strings have been entered AND publish has been pressed, remove text ID from
Does that seem right? Something like that anyway. It seems complicated and brittle, but maybe that is just my slow old mind. I guess at the end of the day there is a certain amount of complexity and that can either be dealt with by explicitly stating the content or by logically inferring it. Either way, the complexity doesn’t just vanish.
In favor of the “additive” approach, it makes it super-clear and explicit to anyone exactly what is published. You can just look at
publication.json and either the whole project is published, or the listed texts. With exceptions, it’s a lot less clear. To work out what is actually published, you have to do:
files in project minus empty files minus exceptions = published texts
Perhaps we need to clarify exactly what
publication.json is for. In my mind, it is the canonical authority of reference for all SuttaCentral publications. If anyone wants to know what we have published, when, or any other central details, it’s all there. I imagine this would be used by apps consuming bilara-data, but also it can be used as the data source to show what is published, or as a reference for researchers or interested parties, etc.
I’m thinking of, say, someone who is interested to make a print edition of an SC translation. Let’s say they want to publish the MN in French. They check
publication.json and what does it tell them? It is “ready for publication”. Great! There’s just one sutta listed as an exception. Okay, not really a problem, that should be done soon. Thery check back a week later: a different sutta is listed as exception. Hmm.
Anyway, I think you see the point. The file should be clear, explicit, and human-readable.
Yes, unless you filter out the empty texts first, as I propose above. But that creates its own problems.
Hmm. In fact we already do this for KN, so it wouldn’t be hard to apply it to AN and SN too.
I like it, it would keep the simple logic and explicit data of adding things rather than listing exceptions, but would avoid letting the number of IDs grow out of control.
I’d like to hear from Karl and Blake on this idea.
Right, I thought of using “publishable”, but then I thought that for ESL speakers the semantics of “publish”, “published”, and “publishable” is probably a bit obscure.
Okay, no problems.