I am glad to see people appreciate my Vinaya Appendix!
Yes, that would be nice! I suppose it’s just a matter of implementation. The hyperlinks would have to go into the notes, which is where the references to the Appendix are found. To be honest, I am not even sure this be done. What do you reckon, Venerable? And then it would have to be implemented by someone. Of course, there is a premium on the time of our busy tech people. I somehow suspect this is not at the top of their list of priorities!
I’m not sure how links are added in notes. It looks like some of your notes have links to other places in the Vinaya. Do you create those by hand/hard code them?
I assume it would be a similar process.
But at the moment when I look at this page, for example, https://suttacentral.net/edition/pli-tv-vi/en/brahmali/appendix-terms?lang=en there don’t appear to be any anchor ids to be able to link to items directly. So that problem would have to be solved first. Not a big deal, but you would probably need to be reasonably sure that the names of the entries were not going to change.
Of course you could always just do a generic link to the top of the page, but seems like if there are going to be links then they ought to go to the right word.
OK, I looked in Bilara itself and it appears there is a cool markdown method that makes use of official segment ids.
So to get something like that it would require a special system be coded, I think. And of course your appendix would need to be done in such a way that it could have segment ids.
I’m going to guess that there are plans for all this since I don’t even see that the “see blablabla” in the appendix itself has hyperlinks yet.
And the footnotes appear to be non-functional, so I’m guessing there is still work to be done.
One good news is that since the glossary is by Pali term it won’t have to be re-sorted when it is translated into other languages.
ETA: OK, I seen now that the appendix is just a simple html file.
Just thinking on my feet here, the link method for the internal Bilara-data segments uses a markdown adaptation. Now, I think creating such a system for this use would be excessive. Why? Because different books and volumes may well approach these things differently. We can automate things if they are widely in general use, but not for specific projects.
Okay, that means that the way to do this is to simply add HTML links. These files are all HTML anyway.
If we want to add links from footnotes to the Appendices, we can just hard-code them. It does mean we need to be confident about the target URL. As a general rule, hard-coded URLs in our system link to the static target on the web, rather than trying to get all the links within, say, an EPUB or PDF file to work internally. As with so many other things, I want to prioritize stability and simplicity, even if it means it is a little less convenient.
Now, the document URL is now established, but the anchors for individual items is not, so that will need to be added. It think that can be hard-coded as well. Maybe what we can do then is to add a “click to copy” on the item anchors? Then when making the footnotes, just “click to copy” from the web page and paste it directly into Bilara?
This could be done with the browser extension or just a greasemonkey script for the author to use if you don’t want it built into the site for all users.
It would be ideal if these links could also work for the epub/pdfs. Epub readers, especially e-ink ones, are not great for looking something up in an appendix like that.
As I look at the project in more detail I can see altogether six different glossaries. I think this makes hyper linking all the more essential.
Also, I notice that in two of the glossaries, (plants and medical) they are each divided into subsections. From the author’s point of view this makes some sense, however from the users’ point of view it is really unfriendly. You want to look up a Pali word and not only do you have to figure out which glossary it is in, but you also have to figure out which sub-section of that glossary it’s in. Bhante @Brahmali, do you think it would be possible to combine any of these?
I see that the terms has substantially longer explainations than all the others.…
Would you consider lumping together into a single list
And then also adding cross refs, e.g. “see such and such” entries, for everything in the appendix-terms and appendix-sectional and keeping them as their own separate pages.
That means the user would have a single list they would go to instead of having to figure out which of 6 lists (with sub lists) they need to access.
Right, I can see this might be an issue. I shall consider lumping the subsections together. This would only concern the appendices on plants and medical terminology.
I am not sure how helpful this would be. Starting with the general glossary (appendix-glossary), it includes all the terms of the other three appendices. Moreover, wherever relevant, it refers to these other three appendices. More importantly, the notes that accompany the translation always refer to the three non-glossary appendices. The glossary appendix is really just a catch-all of terms relevant to the Vinaya; I never refer to this glossary in the notes. In other words, the reader will always be directed to one of the specialist appendices. On the rare occasions when specialist vocabulary is not linked in the notes to an appendix, one would have to use the glossary which then points the way to the specialist appendix. Not much, if anything, is gained by combining them all.
As for the three non-glossary appendices, they rarely overlap. There are occasional overlaps between the plants and the medical appendices, but not many. Rather than merging them, I think a better solution is to give cross-references. Or the information could simply be duplicated.
To my mind, it is useful to have independent appendices. Each gives a collection of terms on a particular topic, which is interesting in its own right. A read through the list of medical terms, for instance, gives you a good picture of the state of medicine in ancient India. This is useful both for students of the suttas and for anyone interested in scholarly research. If we were to combine all the appendices, this nice overview would be lost.
Do you mean references in the notes to the translation? They are already there.
The notes tell the user which appendix to look at, hopefully with a relevant hyperlink at some point! There shouldn’t be anything for them to figure out … I hope!
Oh, Bhante, I’m very sorry. I didn’t realize this. Then it is probably all fine as is.
I’m wondering if you have completed these glossaries, or if they are still under construction. Because one of the first orders of business would be to generate anchors for all the entries. And we wouldn’t want those anchors to change.
I’m also wondering if there are plans to work them into the click-to-lookup feature on SuttaCentral. So someone reading the Pali could get your definitions.
Also, I’m wondering if you have plans to have this work incorporated into the Digital Pali Dictionary, or create your own dictionary file. It would be most useful.
Bhante @Sujato, have you thought much about integrating this Vinaya dictionary data into the existing SuttaCentral dictionaries?
The simple glossary data would be nice to have in the click to look up results. And the other appendixes would be good to have as dictionary search results.
But unless there was some way to generate the html from a single data source, once we created separate glossary/dictionary data then Bhante Brahmali would need to update two places (the html files and the raw data) every time there was a change to the definitions/headwords.
Nah, too much. DPD essentially makes this irrelevant. If there are meanings that are not found in DPD, suggest them to Ven Bodhirasa, he’s very responsive.
I just heard from Ven. Bodhirasa. He said that the monks at SBS are working on adding Vinaya terms to the DPD. He said he will pass on the glossary links to them.
I guess I was wondering if the more detailed information in the terms section would be good in a SC complex dictionary since the way we have DPD data used on SC it only includes the most basic info.
