Some suttas in the Saṃyutta Nikāya have inconsistent numbering.
Concrete example: Ven. Anālayo references SN 35.206 in one of his books. He means to refer to “The Simile of Six Animals” (Chappāṇakopama Sutta) but on SuttaCentral this ID corresponds to “The Interior and What’s Impermanent in the Present” (Ajjhattapaccuppannayadanicca Sutta).
I understand that SuttaCentral’s numbering system is different from some other numbering systems. But the translations cataloged by SC for SN 35.206 are not of the same sutta. The Italian and the Hungarian translations are of the Chappāṇakopama Sutta. By contrast, the Spanish translation and Ven. Sujato’s English translation are of the Ajjhattapaccuppannayadanicca Sutta.
The SC ID for the Chappāṇakopama Sutta is SN 35.247, and Ven. Sujato’s translation is listed under there. But the Italian and the Hungarian translations are missing under this SC ID.
I suspect this to be an unreported issue. If it indeed is, I hope this example helps.
Animals {S iv 198; CDB ii 1255 (corresponds to CDB SN 35.247)} [Thanissaro | Walshe (excerpt)]. The Buddha explains how training the mind is like keeping six unruly animals tied together on a leash.
But the translations listed on SuttaCentral under its own SN 35.206 are not all translations of the same sutta. I wonder if this is an isolated problem or if this happens for other suttas, too.
This may have happened because different language collections use different numbering systems, and if the person who put the translations on SC isn’t fluent in a particular language they didn’t notice that in that language there is in fact a different sutta under the same ID number. Is that possible?
Thanks so much more pointing this out, and for clearly explaining the issue.
As noted, we use Ven Bodhi’s numbering system. I’m not sure why Analayo is doing something different.
There are a few places where numbering Inconsistencies may create this kind of problem, this being one of them.
The standard is, of course, that all translations should follow the same system as the underlying Pali text. However as you point out, clearly there has been a failure of quality control, and volunteers have prepared texts with incorrect numbering. We should have picked this up.
Checking the translations under SN 35.247, it seems that the eleven translations we have there are all correct. So that’s a relief. And checking SN 35.206, it seems that only the Italian and Hungarian translations are affected. So that is also a relief.
Incidentally, this kind of problem illustrates one of the reasons why we are moving to our new translation system. There is a fundamental conceptual problem you get by mixing text and metadata. You have identified a certain text in a certain way, and that means that every version of that text must be handled independently, which will invariably create issues like this.
Under the new system, text is completely separate from metadata, and exactly the same references, notes, numbering and so on apply to every version.
It’s an issue! Unfortunately, it’s one that’s almost certainly true in a number of other unreported instances. I mention this to stress how valuable reporting is and extend further, emphatic thanks to nanavippayutta.
In legacy format texts, it’s hard to completely guard against the problem in cases when suttas are being prepared by volunteers who don’t speak the given language (I’d be very sympathetic to the volunteer concerned in the highlighted cases ). As you’ll know from elsewhere, I spent a horribly long while trying to correct the numbering of Vietnamese suttas, but this was done by deduction with only the help of rather blunt tools, so although I’m fairly confident they’re right, they still absolutely need to be checked by native speakers. The challenge is yet further exacerbated in translations using scripts totally alien to the preparer (already pointed towards here).
Hallelujah!
Weeeell, it’s mostly a relief, but with respect to these two languages it might mean the numbering of any surrounding suttas is also off, so further poking into the matter is needed (I’ll add it to my to-do).
Yeah, it really is one of the many awesome benefits!
Hi @Aminah, please count on me if you need me to do a detailed screening / review of the Portuguese translations currently available and from the legacy site.
As I think both of you know, for the last… ever (at least it feels like since before the time of the Buddha)… I’ve been going over the 65k+ legacy texts looking at the html of our files. In and amongst the process, I invariably run into a variety of other issues. That’s how I got onto correcting the Vietnamese numbering and, to memory, I think I also found a couple of numbering issues in at least Portuguese.
For the time being (what with “much to do”, and all), with regards to existing legacy texts I’ve no plans to do systematic checks, and will just correct as found/reported. However, if either of you are inspired to do a few spot checks you’re most warmly welcome, and certainly if new legacy format translations come in, in either of these languages, I’ll be sure to send them your way for quality control!
Beyond this, I’d estimate that the places in which numbering is most likely to go a little wonky is:
around range files (suttas SC, following BB, has put together, eg. an1.1-10.html, or sn12.72-81.html); that’s both range files themselves, and adjacent files.
points of devitation in numbering in other sources translators’ might have used (eg. VRI’s CSCD), but it’s beyond me to account for that.
Of course, this is in no way to say that errors won’t occur elsewhere, it’s just my thoughts on where any errors are most likely to be. If others have better ideas…
Anyway, have fun!
* Why are AN 1 & 2 skipped? Cos!!! Okay, okay, because the way in which they’re listed on Old SC is different to how their listed on New(ish) SC and it’s just easier to just say “and AN 1 and 2”
I haven’t changed anything to that effect, but you remember correctly: zips are enabled, but only for admins. I’m reluctant to enable this for regular users though, as there is currently no option to scan uploaded files for malware on the server side.
On the other hand, you can use code blocks for long lists of unformatted text like this:
```text
long
list
of
items
```
It uses much less screen and it even gives you a convenient copy link in the upper right corner (click on the text box on desktop devices to show the copy button):
long
list
of
items
I have edited the sutta IDs as code blocks in your original post for you, hope you don’t mind.
Much thanks for getting back musiko. I know how to use code blocks, but prefer to keep things concise.
Could you revert the changes please. Never mind, I shared the lists via a third party. Bit curious about zip files, as I was able to send zips well before I was an admin, or even a mod. Anyway, I understand your concern and am glad there are alternatives.
I had to double check, and you are right. This was enabled back in 2018, and it was reverted recently by a migration script—not manually—and this is why I didn’t remember revoking it.
). As you’ll know from elsewhere, I spent a horribly long while trying to correct the numbering of Vietnamese suttas, but this was done by deduction with only the help of rather blunt tools, so although I’m fairly confident they’re right, they still absolutely need to be checked by native speakers. The challenge is yet further exacerbated in translations using scripts totally alien to the preparer (
Thanks, 
hmmm… good question!
… 
… 