Using SC segments as reference numbers in 2022

So I wanted to get views on how to use SC segment numbers as references in books. Specifically at this moment suttas/verses in ebooks rendered in HTML/Javascript. The idea being that a contemporary bit of writing references part of a sutta. A reference is given in the writing which acts as a link to get the sutta and highlight the appropriate passage for the reader.

So first off. Should I be referencing by SC segment numbers (in 2022) at all?

Presuming the answer to this is yes …

My thoughts so far is that I can reference the sutta followed by a square bracket and put the segment numbers in there.

For example:

  • MN66 just displays the sutta with no highlighting

  • MN66[20.3] would display MN66 and highlights a single segment 20.3

  • MN66[20.1-3] would display MN66 and highlight segments 20.1, 20.2 and 20.3

  • MN66[20.1-21.1] would display MN66 and highlight segments 20.1, 20.2, 20.3, 20.4, 21.1 i.e. all the verses between the two segment numbers

  • MN66[20.4, 26.2] would display MN66 and highlight the individual segments 20.6 and 26.2

Dhammapada references would just be their verse numbers

For example

  • Dhp121 would display all six lines in Dhp121, no highlighting

There are going to be some strange cases where the segment numbers are ranges, such as MN113[22-24.10] - 22-24.10 is just one segment number, so it would be difficult to incorporate that into a range. I guess something like MN113[21.4-(22-24.10)] is a possibility, but now it’s starting to look like computer code.

Would love to hear any thoughts on this and any pitfalls you think I might not have foreseen. Many thanks in advance. :pray:

1 Like

I’d recommend using a colon rather than square brackets. The Main sutta ID comes before the colon, the segment number after it. Also, just a point of detail, but we use a space if it is in capitals, i.e. in formal contexts.

  • MN 66
  • MN 66:20.3
  • MN 66:20.1–21.1 (use en-dash for ranges!)
  • MN 66:20.4, MN 66:26.2 (probably put it in full.)

Referencing is one thing, showing it on the web is another. To show the text, you need to specify the author and language at minimum (otherwise you’ll get the suttaplex card). I wouldn’t try to represent ranges, we’ve tried to do that and it ends in weeping and beating of breasts. I don’t think the usefulness of range-linking is worth it given the technical complexities and brittleness it introduces.

These days if I want to link to a range I just link to the first segment and leave the rest out of the link.

MN 66:20.1–21.1

For which the markdown is:

[MN 66:20.1](–21.1

Above is the minimal specification for a URL; you can add details for text and translation, etc. if you want.


Really nice. Thanks Bhante.

My current thinking is to use just your translation and the Pali (for the suttas). Because the app will eventually end up as a PWA for offline use, I plan to have (the prototype has) a subset of the JSON files (just the files referenced in the app) and opens the sutta in a modal, which also has a link to the suttaplex card (if the app is online). I’m reusing the sc-mini code by @Snowbird as my starting point.

I’m up for a little self flagellation. I think in my use case it would be really nice to highlight the ranges that the writers are referring to and I have a much smaller subset of data that I need to address than you guys.

Thanks again Bhante

1 Like

Well let us know if you come up with a cool solution, maybe we can copy it!


Bhante. having looked at this, what I’d like to do is use a ‘narrow no-break space’   like the first one below. The second one is a normal space

MN 66:20.1–21.1
MN 66:20.1–21.1

Is this acceptable?

The advantages that I find is:

  1. it just looks a bit nicer with the fonts I’m using (Source Pro family)
  2. for justified text the browser doesn’t seem to create any additional space
  3. it’s a variety nbsp so cool for end of lines.

I don’t know if it’s cool. But I have simplified my original solution (which was limited and complicated). I don’t know if this will work for your use, but it is very straight forward in terms of code

So ranges must be in the form of whatever comes after the colon of the segment number in full, so:

  • MN 66:20.1 is legitimate
  • MN 66:20.1–20.2 is legitimate
  • MN 66:20.1–21.1 is legitimate


  • MN 66:20.1–2 is not legitimate

If there are more than one highlight then the ranges are separated by commas. For example

  • MN 66:20.1–20.2, 21.1

All segment numbers have to be consecutively shown, so while

  • MN 66:20.1–20.2, 21.1 is legitimate

  • MN 66: 21.1, 20.1–20.2 is not legitimate

I have started using it in the ongoing public prototype of theMettāShelf - You can see an example of how it’s used in this booklet:

First an array is built of the ranges:

  function BDSegmentRange (segmentrange = "") {
    if (!segmentrange) {return []}
    let output = [];
    const segmentrangeArr = segmentrange.split(",");
    let i=0;
    while (i < segmentrangeArr.length) {
      let [left, right] = segmentrangeArr[i].split("–");
      if (!right) {
      } else {
    return output;

Then the array is passed to the buildSutta function and a class added if a segment falls within a range (left–right).

function buildSutta(slug, highlightArr =[], multiFileSuttaNumber ='') {

  if (multiFileSuttaNumber) {
    printSlug = multiFileSuttaNumber;
  } else {
    printSlug = slug;

  slug = slugStrip(slug);
  multiFileSuttaNumber = slugStrip(multiFileSuttaNumber);

  if (multiFileSuttaNumber) {
    sclinkslug = multiFileSuttaNumber;
  } else {
    sclinkslug = slug;

  let html = '';

  html += `<div class="button-area">
  <label class="checkcontainer" for="PaliCheck"><span class="checktext">Pali</span>
  <input type="checkbox" name="PaliCheck" id="PaliCheck" checked >
  <span class="checkmark"></span></label>
  <span class="sc-link"><a href="${sclinkslug}/"><img>` + printSlug + `<span class="nomobile"> on SuttaCentral</span></a></span>
  <button id="next-highlight" class="greyedout">Next Highlight</button></div>
  <div id="messagecontainer"><span id="messagetext"></span></div>`

  const rootResponse = fetch(
    .then(response => response.json())
    .catch(error => {
      suttaArea.innerHTML = `Sorry, "${decodeURIComponent(slug)}" is not a valid sutta citation`;

  const translationResponse = fetch(
  ).then(response => response.json());

  const htmlResponse = fetch(
  ).then(response => response.json());

  Promise.all([rootResponse, translationResponse, htmlResponse]).then(responses => {
    const [paliData, transData, htmlData] = responses;

    let highlightArrCounter = 0;
    let inMark = false;

    let keyCount = 0;
    Object.keys(htmlData).forEach(segment => {
      keyCount += 1;
      if (transData[segment] === undefined) {
        transData[segment] = "";

      transData[segment] = parseMarkdown(transData[segment]); 

      /* Highlight ranges specified in highlightArr */

      var marker = removePliHead = "";
      const [segSuttaNo, segSegmentNo] = segment.split(":");

      if (segSegmentNo == highlightArr[highlightArrCounter]) {
        inMark=true; // turns highlighting on
      if (inMark) {
        marker = "sc-mark"; //add the class sc-mark
      if (segSegmentNo == highlightArr[highlightArrCounter+1]) {
        inMark=false; // turns highlighting off
        if (highlightArr.length-1 >= highlightArrCounter+2) {
          highlightArrCounter = highlightArrCounter+2;

      /* Extract a sutta within a multi sutta JSON file */
      let printThis = true;

      if (multiFileSuttaNumber != '') {

        if ((multiFileSuttaNumber == segSuttaNo ) && (segSegmentNo !== '1.0') && (segSegmentNo !== '0')) {
          printThis = true;

        if (transData[segment] == paliData[segment]) { //remove duplicate if pali and eng are the same
          removePliHead = "noshow";

        if (keyCount == 1) {
          html += `<header><ul><li class='division'><span class="pli-lang" lang="pi">${paliData[segment]}</span><span class="eng-lang" lang="en">${transData[segment]}</span></li>`;
        if (keyCount == 2) {
          html += `<li class='subdivision'><span class="pli-lang" lang="pi">${paliData[segment]}</span><span class="eng-lang" lang="en">${transData[segment]}</span></li></ul>`;
        if (keyCount == 3) {
          html += `<h1 class='range-title'><span class="pli-lang ${removePliHead}" lang="pi">${paliData[segment]}</span><span class="eng-lang" lang="en">${transData[segment]}</span></h1></header><h4>${printSlug}</h4>`;

      const [openHtml, closeHtml] = htmlData[segment].split(/{}/);
      if (printThis) {
        html += `${openHtml}<span class="pli-lang ${marker} ${removePliHead}" lang="pi"><span class="segno">${segSegmentNo} <br /></span>${paliData[segment]}</span><span class="eng-lang ${marker}" lang="en">${transData[segment]}</span>${closeHtml}\n\n`;

    const sctranslator = `<p id="sc-translator">&#8212; transl. Bhikkhu Sujato</p>`;

    html += sctranslator;

    suttaArea.innerHTML = html;


It’s just those few lines after the /* Highlight ranges specified in highlightArr */ comment and the associated variables outside of that forEach loop.

Big thank-you to @Snowbird for the original buildSutta that I got from mini-sc

That looks more pleasing to me. It’s similar to how units are usually separated from numbers by a thin space, in LaTeX one writes “30\,kg” ( “\,” typesets to a “thin space” in TeX or LaTeX), not “30 kg”. The latter typesets badly since it’s two words, so the space is variable.

1 Like

Really? The latter looks right to me, the former outright wrong. Maybe that’s language specific?

1 Like

Hmm, sorry, I’m assuming too much knowledge of LaTeX/TeX. “\,” is code for a thin space, and that didn’t come out properly in my original post, as the forum markup gobbled up the “\”. I’ll fix it.


You can use the “preformatted text” tool

Screenshot from 2022-06-15 22-05-42

or type ` at the beginning and end of your code string:



can you share a link to your github repo? :wink:


1 Like

OK. I’ve succumbed to the inevitable … it’s here

I don’t know about github yet, but git is awesome. So thank you for the gentle persuasion.


That looks great. And narrow no-break space is exactly right for this context.

1 Like

So I would like to expand this to ask about the Vinaya references.

So say I want to reference 75.1.8 from pli-tv-kd1. What should my text reference look like? Something like PLI-TV-KD1:75.1.8 perhaps?

I was going to use thin spaces in a web project I’m doing, then realized it made it impossible for me to search for citations on the page without copy pasting in the thin space from somewhere. I instead decided to use css word-spacing property.

The pli and tv are redundant, eh? I think Bhante was working on removing one of them. Also, we would usually do Pli Tv Kd, no? Taking Theravada and Khandaka as single words. Or is that not at all what you were asking about?

1 Like

Yes. Great spot. Thank-you once again!! That’s clearly the way to do it!

Yes. This is what I’m asking about. I was really just putting up a straw man to see what people suggested as I am so very unfamiliar with the structure of the Vinaya.

So maybe just something like:

Kd 1:75.1.8 is fine?

If you only need to work within Pali/Theravada. What I meant by redundant is that there is no Sanskrit Theravada Vinaya. So even discussing multiple traditions you only need one or the other. Perhaps they system is there because there are different traditions that use Sanskrit?

And just as an FYI, before coming to SC, I think I had only seen refrences to Mv and Cv, Mahavagga and Cullavagga, as the two sections of the Khandakas.

1 Like

It really depends on context. We have to add the qualifiers to disambiguate from the other Vinayas. But if it’s pali-only, then sure, remove them.

In retrospect, i would not have included the language in the UID. I did it only because it’s necessary for the other Vinayas, which often exist in multiple languages. Oh well, it won’t change now! And it is at least theoretically possible, if extremely unlikely, that we might find a Theravada Vinaya text in ancient Tibetan or Chinese translation.