As more Bibles are being added to BBP, does that increase the client size or memory use? Just thinking out loud here, but could we zip/compress the text into the blockchain and have it retrieved by the client by reading the blockchain database? It would make the blockchain bigger, but I wonder if you can scale better and add more languages of the Bible this way?
3100 BBP
First the succinct answer:
I think, for best practices, it would be best for us to start gathering KJV or NKJV (IE the voted in translation that conveys the best) in multiple languages in PDF formats, from opensource sources, and include these files in our build (not our compile, our build process). What this would do is place these translation pdfs in the bbp application directory - so they would be available for viewing from our Bible Viewer page. We could make new links for the bibles, and we could potentially auto-detect their language and put that link at the top. The link would open the PDF bible in this case. The reason I recommend this is it takes no memory usage, and allows the files to be available behind the 'firewall' in Korea, China, Russia etc.
The more technical answer:
We do need to keep at least the KJV English in, for the POBH hashes for syncing from 0. We do have other code, for example the popup verses that use that reference, and even our bbp-university pulls up scriptures based on book-chapter lookup. I think it would be better for us to make .dat files that do have the other languages version of the 32,000 verses and we could offer bounties for those. It would be in our best interests to do both of these things as Im sure the PDFs are already available. This second feature is more for compatibility for verse lookup features. Its certainly valuable in the code to be able to call for example Matthew 7:7 1-5, and pull it up in EN or another language. But yes I think it would not be feasible to keep adding classes for more translations. We need to move to .dat files for this. A bounty would mean finding a KJV translation in text format - in a certain language - converting that data to a .dat file in our import format --- then we would use this data on the fly when the user switches languages. (Soon we can also mark all blocks as "OK" or grandfathered in up to the end pobh-height also, that will speed up syncing a tiny bit).

6000 BBP