A 4kb mini interface for SuttaCentral.net suttas and Vinaya

Inspired by this post and building on some things I have been doing recently, I thought I would see if I could make an ultra-light interface for accessing the root and translation data of SuttaCentral.net without going through the website.

When you go there you will find some brief instruction.

Big caveats:

  • it’s up to you to give a correct citation/url

So, that means that if there is a range for a particular sutta, you have to give the correct range. For example ?an1.1 will give you an error. It has to be ?an1.1-10

Is it really only 4kb?

Yes. And you get what you pay for, as you will see. There is no nothin’ except the Pali and English of the sutta and Vinaya. And the 4kb doesn’t count the data of the sutta itself. Just the interface. If you can even call it that.

How does it compare with the real thing?

I’m not 100% confident these numbers are accurate, but I think they give a good idea.

Sutta real SC size real SC time mini size mini time
DN16 1.630 mb 23.6 sec .081 mb 2.6 sec
SN1.1 1.360 mb 11.6 sec .008 mb 1.46 sec

Now, those numbers are without caching. DN16 on the main site drops down to .817 mb if it is building from cache. Also, I have the Pali-English lookup turned on for the main site, and it appears that that data alone may be over .400 mb in transfer size (it’s over 3mb on disk)

How does it work

The latest version makes use of the SuttaCentral API

The old version (still available as a branch on github)
pulls all the sutta data (Pali and translation) from the raw files on the github repository. So for example, for SN1.1 it is pulling from these three files:

code

Here is the github repository:

I’d love to hear any feedback. Obviously there could be a lot more to the interface (like an actual interface!) and still not take up much space.

6 Likes

Awesome, great Idea.

Some CSS suggestions:

  • there’s a font-weight: 100 in there. Yikes, don’t do it! The Pali is illegible on my screen. Font weight for body text should always be left at the default 400, it is what god and font designers intended.
  • you can improve accessibility without adding complexity by replacing the classes in the segments with the lang=en and lang=pi attributes. They can be selected like span:lang(en) for styling. And screen readers will have a better idea what to do.
1 Like

Yes, I was just being lazy. I didn’t specify real fonts, I guess to save bandwidth. And the default serif and sanserif font pairing on my device is horrible. I guess if I’m going to care about that, I need to specify the font.

After getting burned by that with the epubs I created, I thought to stick with classes for styling. I’m wondering if it is really considered ok to use the lang attribute for styling, even though it does work sometimes.

Any way, I just added the lang attribute as well as the class. It doesn’t impact the download size.

Thanks for the feedback!

I get it, but there are no really great choices.

  • use browser defaults (ugly and unpredictable)
  • try to second-guess system fallbacks (a fool’s errand)
  • use @font-face (complicated and adds download)

You’re probably best to stick with what you have. Just use something other than font-weight to distinguish them. Best options would be

  • italic and/or
  • color (#757575 is fine; gray is too light, it doesn’t pass a11y tests)

Sure it is, 95% browser support

Browser ≠ epub. Modern browsers are pretty consistent and have good standards support. Heck, lang selector goes back to FF 2 and Chrome 4.

(The reason for wanting to style by lang is so it can support different scripts and so on.)

Ha! They look indistinguishable to me.

Looks like OperaMini isn’t supported, and that’s one of the targets I had in mind. That’s what my dumbphone uses. Unfortunately I can’t seem to get internet working on it to test.

Thanks again!

I’d love to hear if folks have any ideas for lightweight features I could add. I’ve just added a link to the selected sutta on suttacentral.net.

1 Like

Could you hook it up to your search doohickey so I don’t have to type the url manually like a caveman? :laughing::pray: Or… if that’s too big… at least a simple form on the homepage?

(All my mobile browsers make it difficult to manually change the url, assuming people almost never type urls these days)

2 Likes

Nice! Thank you.

Plus 1 for this.

Just a switch to turn the Pali on/off for me

1 Like

I was actually thinking that my search dookickey Citation Helper™ could have a “preview” button to load it in the same page. That way if you weren’t sure if the citation was the one you wanted you could just change it. So, yeah, I need to think about that.

In the mean time, now there is an input box.

Done! I had been thinking about adding that into the url interface, but a button is much simpler.

Thanks!

I’m open to suggestions on design/formatting of those two things.

1 Like

Can the citation box prepopulate with the current sutta as the default value?

Also (:laughing: I realize by the end of this you’ll have reimplemented all of SuttaCentral :laughing: but…) the next feature I’m missing is the “Previous” and “Next” Sutta buttons. At that point it’s basically an ebook! :slight_smile:

1 Like

Done.

It looks like that information is available through the api. You can see it here: https://suttacentral.net/api/suttas/sn7.5/sujato?lang=en&siteLanguage=en for example.

Hopefully we can make some documentation for the API and I’ll see about just switching over to using that. From what I have seen so far, though, the API gives more information than I really need. Of course it’s just kbs. But still I like the ultra minimal thing.

1 Like

If I toggle off Pali and go to another sutta it should probably remember that choice

me too! Omg it’s so nice not having to wait 11 seconds for it to load

1 Like

Would I store that in local storage?

Could. Or store as a hidden field in the form and pass along as a second query parameter. Up to you :blush:

1 Like

Hi @Snowbird … great little tool. Could the Pali headings be toggled off when Pali text is toggled off please?

2 Likes

Great. Thank you

Yes. Absolutely

Nooooooooo! :wink:

2 Likes

Just a little thing:

https://suttacentral.net/an1.328/
gives a single sutta

https://mini-sc.netlify.app/?an1.328
gives: Sorry, “an1.328” is not a valid sutta citation.

https://sutta.readingfaithfully.org/ with an1.328
gives https://suttacentral.net/an1.316-332/en/sujato

1 Like

OK, That’s done. Could you take a look at how I did it and tell me if it makes sense/is the right way to do it? Previously, I was just using .toggle() but that won’t work anymore, eh?

Ah…

Khantī paramaṁ tapo titikkhā,

:wink:

So, for the sutta titles, I really want to keep the Pali there. I have removed it for the little list at the very top that shows the book, vagga, etc. And also for the subheadings within the suttas. If you had a suggestion on how to style the titles better, I’m very much open to that. Did you have a specific use case where you needed even the Pali in the titles hidden?

Right. That is expected at this point. That’s what the instruction Suttas that are part of a series require that you enter the exact series. means.

This is because the json files for the suttas that are part of a series contain the whole series. And I’m just pulling from the raw json files in the github repo.

Right. This I believe is a brand new feature. (Yay!) It is done somehow programmatically.

Yes! That’s because that app contains a table of all the suttas that are part of a series.

So if we wanted the same behaviour in mini-sc it would have to include all those tables as well as code to find a single sutta within a series. And so very quickly it wouldn’t be so mini.

I’ve been trying to figure out the API. This will probably be a better way to get all of the sutta data. However the ability to call on a single sutta within a series doesn’t seem to be part of the API yet. For example:
https://suttacentral.net/api/bilarasuttas/an1.328/sujato?lang=en
gives “Not Found”.

OK. That all makes perfect sense. So cool to have these tools. Thanks you very much Bhante!!

1 Like

TIL the .classname selector has less support than the lang selector (94.13% v 94.48%). Probably just an artefact of the data but still.

1 Like

looks about right! Except I’d just add/remove a “pali-hidden” class on the parent element for the whole shebang and do the rest in CSS:

div.pali-hidden span.pali-lang { display: none; }
…etc

1 Like