SuttaCentral 2021: bug reports here! 🐛

ekay · July 13, 2021, 10:51am

I don’t know whether to call this a bug or I’m possibly doing something wrong, but I’m noticing that when I reply directly to another person, like so:

rather than replying to the thread itself:

I don’t see the indicator that I’m replying to that particular person, which I do see on other people’s replies:

The reply does show up in my count of “Most Replied To” so Discourse can tell I’m replying to a particular person, it’s just not indicated visually. I’m talking about replies where I don’t quote or @ the other person, so I worry it’s confusing to other people if that’s not visually apparent.

Android 11, latest version of Brave. Thanks!

sabbamitta · July 13, 2021, 10:56am

That’s how it is if you reply to the very last post in that thread. Let’s say, so far A, B, and C have posted in a thread, and C has the last post. And now you want to reply to C.

In such a case, obviously, Discourse does not see a need to give a visual indicator and thinks it is clear enough that your reply (let’s call it D) is immediately under C.

Try to reply to A or B instead, and you should see the visual indicator.

ekay · July 13, 2021, 10:58am

Thank you so much for clarifying it, I tried to figure it out on my own and that totally hadn’t occurred to me!

Vimala · August 8, 2021, 10:56am

I’m getting some data loading errors:

Some of them in the bottom part only:

Some just don’t load at all:

I checked the HTML and ran it through a validator but I cannot find anything obvious that causes these errors.

UPDATE: Somewhat later it did work again but I get such data load errors quite often on html texts and am not sure what causes it.

sabbamitta · August 8, 2021, 11:22am

I am getting the same quite often. It seems the site sometimes takes a lot of time to adjust when switching pages. Also note the discrepancies that occur between what the URL line says and what the breadcrumbs say. It seems the breadcrumbs take a much longer time to orientate themselves to find their way to a new page. (I mean, I can relate. I also have no sense of orientation …)

I know that @HongDa did already try a lot to fix it, but so far he hasn’t been lucky.

Perhaps this rather belongs to this thread for technical bugs. @moderators, could you move it?

Viveka · August 11, 2021, 2:55am

Tagging @sujato into this message

Gabriel_L · August 14, 2021, 1:11am

Hi @HongDa

I would like to bring to your attention an issue I have been encountering when navigating across suttas when with the Portuguese language on.

The issue is encountered when I try to navigate from a sutta to the next and it seems to occur when I jump from a sutta translated by one translator to a sutta translated by another.

For example, let’s say I have landed at the page for AN 3.33: Sāriputtasutta, translated by me and others (suttacentral.net).

When I scroll to the bottom and click on “Nidanasutta” at the bottom, the next sutta, I get the following error.

Note that at the address bar we now have https://suttacentral.net/an3.34/pt/null

Note that:
. For AN3.33, there is only a translation by me.
. For AN3,34 there is only a translation by Beisert.

HongDa · August 25, 2021, 10:07am

Hey @Gabriel_L Thank for you feedback!
I’ll check it

HongDa · August 30, 2021, 5:21am

Hey, @Gabriel_L This problem has been fixed!

Need to hard refresh suttacentral to get the latest updates.

Vimala · September 20, 2021, 12:12pm

Bug report from Ven. Anandajoti: When you do not have your ‘main’ references set as ‘on’ in the views, direct links to segments do not work.

(in this case https://suttacentral.net/mnd16/pli/ms#114.2)

Snowbird · September 21, 2021, 9:40am

This has been broken for some time, I believe. It’s too bad.

namrup · October 8, 2021, 3:15am

hello, i found some missing voice link in this site, please note. thank you

AN 1.41–50

AN 1.51–60

AN 1.61–70

AN 1.82–97

AN 1.98–139

AN 1.198–208

sujato · October 12, 2021, 10:25pm

I feel like I’m going back a long way, is it really that long? Anyway, let me address these.

We’re not hijacking default behaviors, it’s just doing whatever your OS thinks is best.

Yes, that should be the case, I’ve opened a bug for it.

This is fixed.

Perhaps not, but a nicely spotted bugette nonetheless. And I dig the screenshots!

I’m hoping this bug has cleared since then, please let me know if it has not.

Other bugs of similar sort I will also leave for now.

Yeah, it’s a hassle to support this kind of non-standard usage. It’s so brittle. This is discussed in an upcoming prject, if you have ideas please add them there:

github.com/suttacentral/suttacentral

highlight textual passages

opened 06:12AM - 11 May 21 UTC

sujato

As well as using `:target` to highlight linked references, we can also highlight… linked *passages*. These will target the `id` on the textual passage rather than the references. This will be used for parallels. Click on a parallel link that covers a section of a text (eg. a verse) and it will highlight the relevant portion. ## Methods There are at least two approaches to this: - Use text-fragment - Add class to segments Text fragment is an emerging technology that is currently only supported on Chrome. Using this approach, we would add a snippet of text from the start and the end of the passage to be highlighted, using a special browser syntax for the URL. Advantages: - keeps the markup clean - no CSS required - ranges are handled easily - it's the platform method for doing what we want. Disadvantages: - Chrome only - How to handle root and translations? Let's look at how this might be implemented. ## Text fragment The URL syntax is explained in detail here: https://wicg.github.io/scroll-to-text-fragment/ The basics are: - text snippets must be percent-decoded. - add `#:~:text=` to the end of the URL - add the (percent-decoded) START text - then a comma - then the percent-decoded END text. Let us assume that the start and end text are the full segment text. For example: https://suttacentral.net/sn1.1/en/sujato We want to highlight a parallel for the first verse. Start text %E2%80%9CAfter%20a%20long%20time%20I%20see End text he%E2%80%99s%20crossed%20over%20clinging%20to%20the%20world.%E2%80%9D Full URL: https://suttacentral.net/sn1.1/en/sujato#:~:text=%E2%80%9CAfter%20a%20long%20time%20I%20see,he%E2%80%99s%20crossed%20over%20clinging%20to%20the%20world.%E2%80%9D Click it, it works! So that's nifty. We just have to focus on getting the URL right, everything else is done by the browser. The tricky part is, how do we handle translations? If we target just the root text, what if the user does not have root text displayed? If we target translation, then we'd have to generate the text fragments per language. Since it would be impossible to do this on the back end, we'd have to dynamically extract the text from the segments depending on the language in the URL. - Suppose we have a parallel reference on a page to segments 4-8. - When clicked, extract the text for segment 4, percent decode it, and add it to the URL text fragment. - Then extract the text for segment 8, decode it, and add it to the URL It's getting complicated. Let's look at the class based approach. ## Adding classes A simple example. Suppose we have a parallel to the following segment. ``` <a class="sc" id="1.2" href="#1.2" title="SuttaCentral segment number">1.2</a> At one time the Buddha was staying in the land of the Kurus, near the Kuru town named Kammāsadamma. ekaṁ samayaṁ bhagavā kurūsu viharati kammāsadhammaṁ nāma kurūnaṁ nigamo. ``` To highlight the text, we might simply allow the URL `suttacentral.net/dn15/en/sujato#dn15:1.2` to activate the CSS `:target` on `id="dn15:1.2"`. So far, so straightforward. But things get tricky when we want to highlight a *range* of segments. Commonly we want to highlight the text for a range of segments. This may be a verse or, for example, a prose sutta that is embedded in a longer text. In the past we tried to support this by adding a wrapper element to the HTML, but this was brittle and hard to keep updated. Unfortunately we cannot use the `:target` method for this as it only supports single IDs, not ranges. It is here that the text-fragment method shines. Here we might add a class to the segments directly. Take the following example: ``` <a class="sc" id="2.1" href="#2.1" title="SuttaCentral segment number">2.1</a><a class="cck" title="Chulachomklao Pāḷi Tipiṭaka" id="cck15.2" href="#cck15.2">cck15.2</a> <a class="dr" title="Dayyaraṭṭhassa Saṅgītitepiṭakaṁ" id="dr15.2" href="#dr15.2">dr15.2</a><a class="ms" title="Mahasaṅgīti Tipiṭaka Buddhavasse 2500" id="ms12S1_3" href="#ms12S1_3">ms12S1_3</a> <a class="sc" title="sc2" id="sc2" href="#sc2">sc2</a> “After a long time I see “Cirassaṁ vata passāmi, <a class="sc" id="2.2" href="#2.2" title="SuttaCentral segment number">2.2</a> a brahmin extinguished. brāhmaṇaṁ parinibbutaṁ; <a class="sc" id="2.3" href="#2.3" title="SuttaCentral segment number">2.3</a> Neither standing nor swimming, Appatiṭṭhaṁ anāyūhaṁ, <a class="sc" id="2.4" href="#2.4" title="SuttaCentral segment number">2.4</a> he’s crossed over clinging to the world.” tiṇṇaṁ loke visattikan”ti. ``` We want to indicate that the entire verse is a parallel. In fact this would be indicated as such in the parallels file. The logic would be: - If there is a double hyphen in the URL - then take the ID before the hyphens and match it. This is the first segment of the range. - take the ID after the hyphens and match it. This is the last segment of the range. - match all segments between the first and last. - add `class='matched-fragment'` to all matched segments. ``` <a class="sc" id="2.1" href="#2.1" title="SuttaCentral segment number">2.1</a><a class="cck" title="Chulachomklao Pāḷi Tipiṭaka" id="cck15.2" href="#cck15.2">cck15.2</a> <a class="dr" title="Dayyaraṭṭhassa Saṅgītitepiṭakaṁ" id="dr15.2" href="#dr15.2">dr15.2</a><a class="ms" title="Mahasaṅgīti Tipiṭaka Buddhavasse 2500" id="ms12S1_3" href="#ms12S1_3">ms12S1_3</a> <a class="sc" title="sc2" id="sc2" href="#sc2">sc2</a> “After a long time I see “Cirassaṁ vata passāmi, <a class="sc" id="2.2" href="#2.2" title="SuttaCentral segment number">2.2</a> a brahmin extinguished. brāhmaṇaṁ parinibbutaṁ; <a class="sc" id="2.3" href="#2.3" title="SuttaCentral segment number">2.3</a> Neither standing nor swimming, Appatiṭṭhaṁ anāyūhaṁ, <a class="sc" id="2.4" href="#2.4" title="SuttaCentral segment number">2.4</a> he’s crossed over clinging to the world.” tiṇṇaṁ loke visattikan”ti. ``` This has significant advantages over the text-fragment approach. - since it is based on segment IDs not text, it doesn't matter whether it's root or translation - the segment ID form is used in the parallels files. (or at least it will be!) - it is supported in all browsers Returning to the simple case of highlighting one segment, perhaps we should not use `:target` for this, so as to not use two methods for the same idea. Instead, perhaps we could utilize the *fragment directive* idea from text-fragments. https://wicg.github.io/scroll-to-text-fragment/#fragment-directive I'm not sure I really understand it, but the idea would be to have a URL something like this: ``` suttacentral.net/sn1.1/en/sujato#:~:range=sn1.1:2.1,sn1.1:2.4 ``` Then use this to add the classes as above.

Indeed. I am still pondering options. In the long term, yes, this would be the ideal, and I would recommend maintaining links to verse numbers for the Dhammapada.

Vatthus are headings, and all headings take a zeroth number. (When you took the screenshot, the headings weren’t displaying properly, this was a separate bug that has since been fixed.)

This is already on the 2-do list: Correct links in Index pages · Issue #1168 · suttacentral/suttacentral · GitHub

Ahh, not sure what to do about this ATM, sorry. But there may be some good news on the Disctionary front, so stay tuned!

Sorry, this is a function of the hyphenation algorithms or lack thereof. We’ll revisit our implementation, meanwhile please upvote adding language alias to CSS:

github.com/w3c/csswg-drafts

[css-text] Allow alias for language hyphenation

opened 01:34AM - 30 Jun 20 UTC

sujato

css-text-4 i18n-tracker

The CSS spec provides for hyphenation of text, leaving the choice of language up… to the UA: https://www.w3.org/TR/css-text-4/#hyphenation Currently Firefox offers the best support, but even they only support fairly small subset of the world's languages. https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens The thing is, it is sometimes better to have imperfect hyphenation than none at all. No hyphenation can result in a broken UI and unreadable text, whereas imperfect hyphenation might work fine, or at worst be merely inelegant. I work with texts in Pali and Sanskrit, which can have very long words formed by compounding. There is no browser support for hyphenation for these, nor is there likely to be. Surely these are not the only languages affected. Here is a typical example, rendered in firefox: ![Screenshot from 2020-06-30 09-26-16](https://user-images.githubusercontent.com/6112010/86071515-ccc36280-bac2-11ea-8338-b6cee8657cdf.png) It is possible to hack around this by activating hyphens and setting `lang='la'`: ![Screenshot from 2020-06-30 09-25-58](https://user-images.githubusercontent.com/6112010/86071483-b6b5a200-bac2-11ea-906e-5b711bc018b8.png) This is identical to the result that a proper Pali hyphenation would produce. Note that in tradition Indic orthography, there is no concept of a correct breakpoint; scribes merely wrote to the end of the line and continued on the next line. Thus the traditional practice would agree with the idea that sometimes *any* breakpoint is better than none. However, it's obviously not a good idea to deliberately set a false language. Hence my proposal: **Allow the CSS to declare a language alias for hyphenation**. So the text language is unaffected, and the HTML does not change. But the user can declare via CSS something like: ``` hyphenate-alias-languages: pli, la; ``` Meaning: "for the purpose of hyphenation, Latin and Pali may be substituted." Such substitution would apply only if explicit support for that language is missing. So if `lang='pli'` is set on the HTML, then if one UA has support for Pali hyphens, that is used, if not, it looks for support for Latin.

This seems to be fixed now.

Hmm, I’ll fix it.

As for the title issue, I made a bug report for that yesterday as it happens.

github.com/suttacentral/suttacentral

Sutta Titles extracted for suttaplex are not always correct

opened 07:49AM - 12 Oct 21 UTC

closed 11:48PM - 13 Oct 21 UTC

sujato

The translated sutta titles in the suttaplex should be taken, 1. From the `na…me` files 2. If there is no `name` entry, from the segmented sutta translation. The latter appears to be buggy. See the following: ![Screenshot from 2021-10-12 18-44-00](https://user-images.githubusercontent.com/6112010/136913808-8645ec88-70ab-4d3e-a822-505ee741e35e.png) Every sutta is name "Chapter 2"! I think the cause of this is that in this collection, `iti` (Itivuttaka) there are four segments inside the `<header>`. And I believe the program is mistakenly selecting the third element for the sutta title. - **The sutta title is *ALWAYS* the *final* element in the sutta header.** It is always marked with `<h1>` in the HTML files. Note that this particular case, the Itivuttaka, should be fixed as I have manually entered the titles in the `name` files. Still, we should make sure this function is implemented properly, as it may affect other texts.

It looks like the errors in the footer are probably the same bug.

More soon!

sujato · October 12, 2021, 11:33pm

Huh, I must have messed this up when I changed our verse formatting. I’ve fixed it now.

Oh, there was a missed placeholder in the files, I have fixed this and a few other instances.

Oh, right. Hmm, looks like the prev/next algorithm is broken in these cases. I’ll make a bugfix report.

We’ve addressed these problems and I believe they are fixed. I think it was caused by the way JS was loaded.

It now doesn’t show an error, but it takes you to the Pali text. It should show a translation by default. I’ll file a bugfix.

There’s a reference project in the pipeline, we’re getting to it.

Oh thank you. It seems the Voice links are per-sutta, so it gets tripped up when we have a bunch of suttas in the vagga.

I’ll make an issue for it.

stu · October 13, 2021, 12:21pm

This is a problem around the history interface I think. There is one problem with Chrome and there is an additional problem with Firefox (I’ve only checked those two browsers on Windows 10).

The back button behaviour is a bit unexpected.

In Chrome - If I’ve scrolled some way down a page such as suttacentral.net/mn and then click to go to (for example) suttacentral.net/mn9/en/sujato. If I then press the back button, it goes to the top of the previous page instead of where I had just come from (a bit down the page).

In Firefox - The same problem appears as in Chrome, but I’m also forced to press the button twice.

HongDa · October 13, 2021, 1:33pm

Dear @stu Thank you for feedback!
This is related to the recent update and I will be looking for ways to fix it.

HongDa · October 14, 2021, 3:22am

Hey @stu, The issue has been fixed and has been released to the server.

Tip: A hard refresh of your browser is required to get the latest version.

Vimala · October 14, 2021, 5:46am

I think it is fixed. I did not get this problem for some time any more.

Thank you for your answers!

mikenz66 · October 27, 2021, 8:29am

Therigatha Chapter 4 currently only has one sutta! Using Chrome on Linux or Windows.

Snowbird · October 27, 2021, 8:47am

That’s because there is only one set of verses there.