Prev-Next in DN navigation

@blake @sujato

In the Navigation pop up window on the left of the DN suttas … it jumps from DN2 directly to DN15 giving the appearance that the intervening suttas are missing (which they aren’t - one can access them by typing the sutta number in the address bar)

Keep up the excellent work

Khinabija

1 Like

This has been fixed. It was a (much) wider issue than merely the DN. Basically there is a mechanism for explicitly declaring the next and previous text, some of these explicit declarations had become outdated. I rewrote the code which calculates next/prev so it preferentially uses the ‘division order’ from the sutta tables (when looking for the next sutta after en/dn2, it first looks to see if en/dn3 exists), this works great for things like vibhangas where the order needs to be given explicitly to make it over thresholds such as pj4->ss1 where natural sort cannot be relied on to give the proper order. In cases where there are gaps (i.e. if en/dn3 didn’t exist) it falls back on the implicit declaration or the natural sort order.

This fix also fixes other issues, like some of the vinaya texts didn’t have the proper next/prev links, the pali vinaya vibhanga links went all over the place.

A note for text editors such as @sujato, consider ‘next-uid’ and ‘prev-uid’ to be obsolete, in the case where the uids of texts align properly with the sutta uids, OR, when the natural sort order is sufficient, there is no purpose whatsoever in using it. The only case where it might be needed is where a sutta text is followed by a ‘subdivision length text’ or something weird like that so the uids don’t match up well.

1 Like

Thanks @blake, much appreciated. @Vimala should also know this as she usually includes the prev/next links; I don’t.

@blake, I’m getting an error with the new prev/next. Go to

Then go forward to the next page and you get this

http://suttacentral.net/None/an1.22#22

This should be fixed now, along with a problem where entering a url such as /pi/an1.22 would not redirect to /pi/an1.21-30, but instead would serve the vagga as /pi/an1.22, it now redirects to /pi/an1.21-30#22

Looks like there are still a few edge cases which cause problems. The web crawler bots are really good at exposing these link problems ;).

I’m not actually putting it in: it’s the finalizing tool. However, I noticed I can now only use the tool on the SC local host and not the life version. Maybe I missed a post on that.
Also noticed the the finalizing took creates unnecessary \n in the texts so after using the tool I have to remove those again.
Can @blake or @sujato please update me on the use of the tools i.e. are they outdated or can I continue using them? (I only use the finalizing tool because it is easy to split a file into multiple suttas with the correct headings and give it the correct filenames).
Thanks.

It’s kind of unmaintained. It’s good to know what you use it for so I can do a quick update to bring it up to speed.

Yes, I don’t use it. For splitting files I use @blake’s excelent split.py.

These days my process is something like:

  1. Get hold of the files in HTML.
  2. Run an aggressive tidy over them.
  3. Use cat to join the files into one, usually a division.
  4. Clean any remaining cruft with regex.
  5. Create markup and ensure the suttas have their own <h1> with correct numbering, proper sections, and numbered split tags, eg. <split name="mn1.html">, but leaving out tags that are singletons, such as <html>, etc.
  6. Run a soft tidy, allowing <split> tags.
  7. Ensure there’s a <meta charset="utf8">.
  8. Run split.py.
  9. Run soft tidy over the splitted files, to create the <html>, etc. tags.
  10. Add the <meta author="somebody"> tag to the head.
  11. Throw them in the relevant folder and git them!
  12. Then realize I’ve made heaps of mistakes and fix them… :unamused:

Whatever is most useful. If you send me split.py I can have a look how it works on an old file.

By the way tangentially related to this is I added a different way to add ‘author’ information, at the moment the author is only used to provide a HTML title tag on links to the text. But anyway, the method is this, you can create a ‘metadata.html’ and put it within the texts folder structure. An author defined inside it will be ‘inherited’ by all html files within that folder or descendants of that folder. See for example texts/pi/metadata.html, the details within are automatically applied to everything within the pi folder tree. Naturally if you put a metadata.html in a subfolder, it would take precedence within that subfolder, and metadata in the html file takes precedence. So essentially a metadata.html provides a fallback for when more specific metadata isn’t available.

I am considering making this function work for the complete text metadata, such that you can omit the <aside id="metadata"> altogether, if a metadata.html is defined somewhere above the html file. I know this is problematic for some licences, some licenses stipulate that the license terms must be included in every file it applies to. However my understanding is that CC licence does not require this, it is okay if the licence terms are separate to the piece they apply to (this makes a lot of sense for art and stuff - you don’t want to have to contaminate the thing with the license).
This kind of thing can be both more and less error prone. More, because it can easily end up applying to things it’s not meant to, and less, because of the DRY principle, you just need to do it right once, and the correct details are applied everywhere applicable, you don’t have a dozen different versions of metadata which really all should be the same.

I can see how this is more efficient, rather than defining the metadata for each file, as we have now. On the other hand, most of the actual file-adding work is done, at least until my translation project is finished, so I’m not sure that we’re gaining much.

And we would be losing some portability: at the moment, anyone can just take our file and use them, just throw them at a browser and they work fine, you can publish them anywhere like that. If the metadata is stored separately, then this becomes no longer legal: you have to figure out a way to incorporate the metadata. Not a big deal, obviously, for any competent developer, but still, I kind of like the idea that the text files are complete and portable.

In any case, we would still have to retain the current system as the default, as there are many cases where there is multiple attribution within a folder, which would have to supersede the more general approach.

On a related note, if we could pull the <meta author="foo"> data out of the <span class="author"> in cases where the metadata was missing that would be cool. Also, as a long term cleanup thing, I used to put “Translated by foo” in the metadata, we should just have the name, we can add the rest later if we want.

It’s in the SC /utility folder.

It was actually already meant to do this but I see I put ‘#metadata > .author’ instead of ‘#metadata .author’, gotta love programming.

Otherwise I basically agree with you. Portability favors having the metadata in the file it applies to.

I also agree with Bhante - most of my adding texts is almost finished and adding the metadata is not a huge amount of work.