The update applies to texts, not to suttaplexes. So we’ll either have to update the Dhammapada to point to a text, or, better*, apply the same method to suttaplexes also. Not easy!
(* The reason it’s better is because the static files are translatable, so if we point to a specific translation in English it complicates the translation process. Obviously the translation could update the target text for their own language, but that then generates more complications. What if there aren’t any? What if there are more than one? What if there is a poor translation, and later on a better one is added? It’s easier and more robust to simply point to the suttaplex, and let the reader choose.)
It’s a pretty complex update, as it violates the basic assumption that everything is built on, namely, that one file is one “sutta” (or range of suttas in this case).
We’ll be looking at other cases where this assumption might be broken; one such case is the opposite, the very long texts such as DN 16 or Kd1.
Take Kd 1 as example. There are about 3500 segments. Now, if we have text and translation, with references and Pali lookup, we end up with about 60,000 DOM nodes. The recommendation is to stay under 1500.
On a decent modern machine, it’s not really a problem. But add in mobiles, old machines, and slow devices gunked up with viruses, add-ons, and garbage, and it’s not going to work all that great.
The solution is to chunk up the text, break it on sub-headings, and serve it per-chunk. But this will have to be done by the application, not the data. (In the past, we had a system for the Dhammapada that let you see it in chapter or whole text, but that was based on data, so any updates had to be done to multiple sources.)
Anyway, point being, this is a process, we’ll take it one step at a time.