Among the many awesome features of SuttaCentral 2019 was the Yellow Brick Road, as described in the announcement. The Yellow Brick Road highlights texts translated into the user-chosen language in SuttaCentral’s sidebar.
I wonder if the same system can be implemented for parallels. For example, the screenshot below shows the parallels for SN 1.1:
However, it’s not immediately clear if any parallels are available in English translation (besides SN 2.18). I think it would be helpful to extend the Yellow Brick Road to guide users toward parallels translated into the user-selected language.
It’ a good idea, let’s think about how the UI would be implemented.
In an earlier version, we had proposed having all the text data for each parallel, but it is just too much. However a simple green dot or something to indicate the presence of a parallel could be nice. Maybe a green dot in the top right corner?
Below is a minimalist rendering for the idea. After clicking on the parallels button, the green dots indicate the parallels in English translation—in this case only SN 2.18.
I wonder which link would be most suitable for translated parallels, one to the Pali text or one to its translation. For example, SN 2.18:6 might redirect to suttacentral.net/sn2.18/pli/ms#6, as it currently does, or to suttacentral.net/sn2.18/en/sujato#6, which would be more accessible (this depends on the latter translation being segmented). For full and resembling translated parallels the suttaplex could be linked, e.g. SA 1 might link to suttacentral.net/sn22.12 rather than to suttacentral.net/sn22.12/pli/ms. Just throwing out some ideas…
Cool, thx, that looks I think quite okay, we’ll discuss it further.
You have hit on one of the basic difficulties of this, exactly what are we linking to?
Currently we behave as if the root text were the fundamental thing, and the parallels link to them.
Ideally, we would link to a segmented text that showed both text and parallel, where we could reliably assume they used the same reference numbering. But currently, and for the forseeable future, this is only available for a portion of the texts.
One thing that we should research before deciding: to what extent do the translations of non-Pali texts share the referencing IDs of the root texts? I’m guessing, not always, but it would be good to check the details. If we can rely on the translation and root text having the same reference system, things get easier. @Aminah could you look into this?
It may be related to the Infinite HTML Reform project. For example, we may find that the same references have different names. Hopefully not!
Let’s look at an example, say the Prakrit Dhammapada. text is here:
Translation is here:
Now, let’s see!
Text has IDs of the form pdhp1; translation has the same. Yay! So we know that if we link to a specific verse, we can use the same verse number and just change the language/edition. That’s what we want.
I expect that generally speaking these numbers will be correct, as it is normal in these cases for there to be a single reference text. But it may be that the references are missing, or conventions are recorded differently; and there are some cases where the same text has been published more than once.
It wouldn’t be too difficult to make a script to extract the ID classs for text and translation. But there’s not all that many texts, so maybe just checking them by hand would do.
Yes, that’s a little clumsy if you are looking for English translations. For example, I was looking for translations of parallels to SN56.11 Koṇḍañña in SN56.11 Dhammacakkappavattana parallels and it was quite a performance to click on the links, then edit the address to get to the suttaplex (is there another way to do that?), and then most of them didn’t have translations…
For me, linking to the suttaplex would be more useful. The original language is only one click away, and all the information is there.
Yeah, just a plain list of links to all available translations under the parallel name (lang codes) would be great! Just as a proposition. Something like this:
And the original title leads to the original text.
As a separate note, it would be niceif on a sutta page there would be a dropdown to select translation, so you don’t need to dig into menus to change it, IMO.
I trust you’re referring to the HTML Living Standard; the update to SC’s HTML is assuredly a finite task due to be completed at least a day or two before the end of the world.
In any case, gotchya! Will have a look.
Many thanks, but can you explain this point a little… it seems to me this feature already exists:
And clearly it is not visible enough: there is a proposal for making it more accessible.
Thanks for taking the trouble to do a mockup, but that’s not going to work. The links are too small, not mobile-friendly; there will be too many of them in some cases; the extra data will slow things down (thousands of extra links and associated DOM nodes on some pages), links clutter the UI, they do not follow Material Design guidelines, clickable area is no longer the entire field, clicking the title is not good design (again, contradicts Material design, where clickable fields should be explicit) …
UI is hard! We’ll give it some thought. I’m strongly leaning towards the original yellow Brick Road proposition: indicate that there are translations, while giving a single link to the root text with suttaplex; or perhaps, preferring link to segmented text where available.
Mm yeah, I’m not a UI expert. But indicating somehow that parallels do have translations in certain languages would be great. For example, I’m trying to dedicate some time for translating agamas from english into russian, but who’s going even know that there are such translations? But if a user opens a list of parallels and sees there’s a translation available (somehow), he/she would be more encouraged to investigate. Just thoughts.
In short: we’d better hope we need something else, because this is most definitely seems to be a case of not getting what we want! As things stand, it only looks feasible to link to the beginning of a text and not any specific verse.
Of the 4196 modern language translations of non-Pali texts currently available on SC, 376 have some kind of ID (although some of these look to be ‘junk’ IDs probably resulting from some mishap in processing). Of those few, there aren’t all that many matches (although in a few cases it should be trivial to make an amendment so that they do match). Here’s the lazy results presentation (if you want more info, ask):
Of course, the above just covers translations from a non-Pali root language, but there are also many inter Pali Canon parallels. Of the 49,694 translations from Pali, 26,402 have some kind of id (I haven’t looked at the ids at all).
So as I say, from where I sit, the very lovely idea of linking to verses won’t work atm.
With respect to the IHFP (Infinite HTML Reform project), yes, this point meanders quite closely by a point I already had on my list of things to raise: SC’s anchor ids, to me at least, appear rather willy-nilly and if remotely possible it would be nice to maybe bring them closer to a state of uniformity.
In all honesty, I haven’t really been able to grasp what underlying scheme has been followed and based on my solitary wonders through HTML-land it just seems a collision of “whatever seemed like a good idea at any particular moment” over all time. A number of the classes very helpfully preserve well-established reference numbers (PTS and so on), but others I wonder about the use of and if it would not just be better to stick with a standardizing sc (fair-dos if this is just ignorance on my part).
Equally, no-one’s ever really explained to me where and why data-uid is to be/has been applied (almost all of the above is based on plain ol’ id). Is this a new standard that should be introduced more broadly?
Lastly, as a website user whose felt the ‘humph’ of not being able to link to a specific page part enough times, my feeling is that it is a moral duty for any site to include anchors in its pages (particularly if they contain a lot of text). As per the above, by my calculations at least 27,112 texts have no anchors.
We have that many? Okay! Checking, it seems we have 700-ish in English, some in Russian, German, and Indonesian, and over 3000 in Vietnamese.
Okay, good, now we know.
The general idea for legacy texts is that:
Where a source text has reference IDs, these should be preserved.
Where the source reference IDs follow a pre-existing system (eg PTS numbers) they should be labelled consistently.
We haven’t added IDs or attempted to systematize them. And we won’t: this is one of the things where it is better to just leave the past behind and focus on the new JSON system. But of course if things are broken or easily made compatible, that is fine.
data-uid is a special case that is used for texts that do not readily fit the “one text= one HTML file” pattern. This includes the ones and twos of AN and the Dhammapadas. The idea is that we can include multiple sets of IDs for handling different situation. To what extent they are actually used and properly applied I cannot say, perhaps @blake will know better.
It’s easy to add arbitrary anchors, we can just add an ID to <hX>, <p>, <ol>, <ul> elements that are currently lacking them. There will be no consistency between editions (which is already the case so that doesn’t change) but at least people can link to the bits they are interested in.
Thanks. Yes, it would be great if Blake could say exactly how this is meant to be implemented, because looking through the legacy vagga-suttas, it is applied in some cases, but mostly not (just regular ids are used)… now might be the ideal time to apply it to all the vagga-suttas as I’ve spent a lot of time on them in the IHRP anyway.
Quite so, but if it is to be done… it still has to be decided to be done.
I trust you’re referring to the HTML Living Standard; the update to SC’s HTML is assuredly a finite task due to be completed at least a day or two before the end of the world.
