MS Internet Explorer is currently only used by about 0.5% of web users. However, I have recently tested several different text-to-voice websites where you can enter a URL and the program will read the text to you in a very realistic natural sounding AI voice. With several of them, your website rejects the request to get the text of the sutta because your website incorrectly thinks it is MS Internet Explorer. As a very specific example, you reject queries from the website https://elevenreader.io when I enter the URL SuttaCentral (Unfortunately, the text editor for this feedback page won’t display the explict URL and converts it to look like SuttaCentral.) Because IE is essentially nonexistent, I suggest that you remove the code in all of your webpages that prevents the sutta from being displayed. That code only breaks good uses of Sutta Central.
Thanks for the report!
Can you share an example TTS site that doesn’t require an account to test?
(BTW, the post composer does convert links to the title of the page, and in our case all SC pages have the same title initially. If it’s important to show the exact link, just use the 
in the tool bar and wrap the url in the url code. Alternatively, you can always just wrap the url in back ticks to make it appear as inline code.)
Can you be more specific about what error you are getting and what you mean by “reject queries”?
IE has been End-of-Life (EoL) for some time now, and is not supported by the site. If you use an older browser, you should get an error message that includes a line saying that “IE will not be supported.”. The message says things about other browsers as well and is not specific to IE.
If you’re referring to that message (it’s not clear what your error is), then that would suggest the app parsing it doesn’t support modern CSS[1].
In that case, I would suspect it doesn’t run JavaScript either and is attempting to only read HTML, which would make this duplicative of various past issues regarding parsers without JS (see also the relevant GitHub issue as source-of-truth). If so, that problem has no relationship to IE.
If that is the case, you could workaround this a few ways:
- Use SuttaCentral.Express or SuttaCentral.Now depending on the language you are reading in
- Have the app you’re using pull from SC’s API directly instead of the HTML, e.g. https://suttacentral.net/api/bilarasuttas/an10.211/bodhi
- Use a different app that runs JavaScript
- Use an app that can run in a browser extension after the page has loaded in your browser
As general bug reporting advice, rather than starting with a proposed solution (like “remove IE code”) based on various assumptions without references, it is better to give as many details as possible about your problem, including screenshots, full error messages, and a list of steps anyone can follow in order to reproduce the problem. Similar to how you would give a doctor a detailed list of symptoms with the specific order and times they occurred, rather than suggest to them a medication while only partially describing one symptom.
Without those specific details, someone has to work backwards with fragmented information to figure out the problem, to which the solution may be entirely different than what you proposed. That is substantially more difficult (requiring guesswork and inference) than if anyone can reproduce the exact problem with the exact same error message.
That reminds me that you can wrap it with greater than and less than symbols, < and >, i.e. <http://suttacentral.net/an10.211/en/bodhi>, which renders as: http://suttacentral.net/an10.211/en/bodhi.
If you’re linking to the default translation (en/sujato, en/brahmali, en/kelly), you can also refer to it by its abbreviation, which will be auto-linked, such as: AN10.211
Which it doesn’t necessarily need to to read content, but layout information can be useful to figure out what to read. ↩︎
Huh! Today I learned. Tomorrow I will surely forget, lol.
For troubleshooting, posting the links is probably better than relying on the auto-linker. It’s not perfect technology either.
I literally remembered this syntax in a PR two weeks ago, then forgot about it in a comment 3 days ago (now edited), then remembered it again now 
There’s a lesson in anicca somewhere there
You don’t need a paid account at elevenreader.io, but you can use a free account for 10 hours per month. I spent a lot of time looking for decent text-to-speech readers, and I don’t think there exist any good one that don’t require an account.
Sutta Central misidentifies itself as MS Internet Explore at the URL https://suttacentral.net/sn8.5/en/sujato?lang=en&layout=plain&reference=none¬es=asterisk&highlight=false&script=latin
I looked directly at the code for your webpage and there is an embedded script that gives Eleven Reader the message:
“Oh no! It looks like you’re using an unsupported browser. The site works well on modern versions of Firefox, Chrome, Edge, Opera, or Safari. IE will not be supported.” That’s what the screen reader sees and reads.
Thanks for this. The need for special IE support or messages is long gone.
Nonetheless, it would seem the bug is at the elevenreader end: somehow it must be identifying itself as IE in order to trigger this warning. Never mind, @HongDa can you remove the IE error message and all related code? I think it’s just technical debt at this point.
Bhante, as I wrote above, it’s not specific to IE and applies to any browser that doesn’t support modern CSS. Removing that may not necessarily fix this issue as it’s also part of the default HTML – if the app only reads HTML and doesn’t run JS, it will still have a problem reading the page.
Yes that is the error message I linked to. You seem to have misinterpreted the message: it doesn’t say you’re on IE, it says “you’re using an unsupported browser”, one of which happens to be IE. As I linked to, it displays for any browser that doesn’t support modern CSS, as those browsers will be unable to render the page correctly. It’s also part of the default HTML - it’s always there, just not always visible.
For bug reproduction, it’s good to have something that produces the same error and doesn’t require an account. It produces an error, so the fidelity of the voice output is irrelevant to the bug itself. Was there an app you used that produced the same error and did not require an account?
Okay, but I wasn’t really trying to solve the problem, which as I understand it is on the ElevenReader side. If you think we should keep the backwards compatibility code, then fine.
As I understand it, the real problem is whatever ElevenReader is using to parse our website. The OP refers to
There is no such code. The client, ElevenReader, fails to parse the site and we display a note telling the user that.
Our compatibility standard has long been to support modern browsers, especially the most recent couple of years of the mainstream browsers. App makers should do the same, and we can’t chase every nonconforming app.
I’m not sure I’d call it backward-compat code per se, it’s more a fallback. I’m thinking of the use-case of say, a monastic dusting off an old laptop and visiting SC, and then the layout being all wonky and not working properly and them having no idea why. The current error message at least tells them the problem.
But the fallback code could perhaps be more minimal or adjusted a bit, per below
Confusingly, there are a few lines in this fallback code that do in fact remove site content when an unsupported browser is detected. One has to then manually click to proceed anyway to get back the site content.
So, if say, ElevenReader could actually run JS and just not modern CSS, then that removal could prevent it from parsing a sutta. But I doubt that’s the case as that would be a very odd combo.
That fallback code could potentially be modified to just display a simple modal instead of making any content changes, which could solve a case like that and use less code.
I bit the bullet and made an account to test with. Fortunately, you can delete your account.
As a disclaimer, I did this mainly to test my hypotheses, otherwise, I would not expect any site to go through this much effort to check compatibility with a third-party site (especially not a site run on donations and volunteers like SC, compared to ElevenLabs being a multi-billion dollar paid app).
I couldn’t find any documentation what-so-ever on how their parser works, so making something compatible with it is totally opaque (and it is an AI reader, so not exactly something SC supports, although TTS is more of a gray area).
This immediately fails validation with “THE URL IS NOT VALID”. I had to make this an https URL for it to work.
Then it seems to import a page very similar to non-JS parsers, as I predicted above, as it is only parses the default meta tags before the JS updates them:
The content of that import is indeed the HTML text of the unsupported browser page, because it’s always there (but invisible by default), and no JS has run (afaict):
Ironically, ElevenReader has a browser extension. And if you import an already rendered page from your browser, that indeed works much better:
Notably, I have references disabled, but it is still reading “SC1”, “SC2”, etc. Why? Because it is present in the HTML, but it is invisible unless enabled. So that would seemingly confirm that ElevenReader is purely parsing HTML, and disregarding CSS and JS.
It is skipping the navigation and options buttons at the top, interestingly enough, so seems to be able to identify the <main> HTML element or something.
This is different from the macOS screen reader, VoiceOver, which reads the top bar and then reads the content of the sutta. The screen reader only reads visible content however, and not any invisible HTML. So ElevenReader’s parser is not only undocumented, but also doesn’t follow the behavior of screen readers 
Browser extension code is public, so I was able to parse through some minified code from the extension to find this function:
Which indeed just takes the raw HTML of the page and sends it over to ElevenReader’s API
I did also go ahead and try this, and https://suttacentral.express/an10.211/en/bodhi imports almost identically to the browser extension import, including the invisible references from the HTML.
So with that test data, I’m going to concur with my original comment and say:
- the general problem is a duplicate (non-JS parser)
- the specific problem can be resolved via multiple different workarounds
- it is unrelated to IE (which was an assertion based on a misreading); the site does not have IE compat code and does not “reject queries” (which nominally would mean 4xx error codes), it just needs JS to render
- agree with Bhante that this is at least partly a downstream problem of ElevenReader’s parser
Wow Anton, thanks for going above and beyond.
Yes, thanks so much for that. If there’s anything reasonable that can be done to improve things, let’s do it.
The simplest thing I was thinking was to change the error message to a simple alert modal (which exists in the first version of most browsers), but that won’t solve this problem based on my analysis, so I’m not even sure that’s worthwhile to do. It would be a bit less code to maintain I suppose.
We could also suggest the user try SC Express or SC Now in that error message and the <noscript> tag too, which may have helped in this scenario.
I can write up a PR(s) for either if that is acceptable.
Beyond that, I think eventually moving to the SuttaCentral.express approach of pre-rendering most HTML (which you had liked before) is the optimal solution for this non-JS parser root cause. But it’s a pretty massive refactor, so not something that will be done short-term of course. I’m thinking about some smaller refactors to make that easier, but those will take me some time to get to too.
Yeah, I have to admit I’m lacking enthusiasm for yet another rebuild of SC. For myself, I’d like to keep working on incremental improvements over time, and encourage others to build new apps (like SC Express or SC Now) on our work.
One thing I would like to do is think of ways to better support those third party apps.
Hello Friend,
I have found that using ElevenReader for the Pali Canon has been a pleasurable experience so far.
My tips for my success were as follows:
- I downloaded the epub copies of the nikayas
- I used calibre and a regular expression to remove the footnotes.
- For the SN and AN I opted to delete the table of contents at the start of each chapter. This was mostly to reduce indexing and make browsing easier. (The brevity of these passages means these spoken ebooks aren’t used often.)
- I uploaded the modified epub books onto elevenreader.
This has allowed me to have very easy control over the sutra . I use the elevenreader table of contents to jump to where I want, and play from there.
Generally it has proven to be a solid, and mostly simple experience
I hope this helps guide you in the future .
Thank you for reading.