The Digital Pāli Reader is a tool much like a hard-copy language reader. The tool includes the Pāli canon and related scriptures. It includes multiple dictionaries to facilitate reading the scriptures. In addition to enabling an immersive experience for the study of the Tipitaka, it is also useful in the study of the Pali language at an advanced level. The Digital Pāli Reader is used by Buddhist monks in their Pāli studies, at Universities around the world and by lay users for study at home.

Current backlog is maintained here.

To get DRP running on the local machine:

1. Install live-server: npm i live-server -g
2. Run live-server in root folder: live-server
3. Browse to http://localhost:8080

The current codebase has organically evolved since the last decade. Every piece of code implements some critical functionality.

For the following reasons working with the code base is tricky:

• Lots of students, professors, monastics depend on DPR for their day to day work.
• Code and markup aren't cleanly separated, special care must be taken to not break stuff when changing the code.
• Manual testing process are not yet streamlined.

Over a period of time with care and above infrastructure support (linters, prettiers, testing processes), the code base will evolve to be much easier to change.

Here is an excellent book for techniques for working effectively with legacy code.

This is a 'live' section. Feel free to suggest amendments through PRs.

1. DO reuse existing code. Remember that features that are being ported over from XUL to Web are already working.
2. DO make only the minimum changes necessary for implementing features, fixing bugs. VSCode will auto format those changes as per .editorconfig and other settings.
3. DO abstract out HTML ids behind PAL interface. E.g. DPR_PAL.getDifId();
4. DO ask for buddy testing.
5. DO test all scenarios (TBD: Link to manual test scenarios that every commit must pass)
6. DO resolve all PR comments through discussion.
7. DO follow the project conventions for all new code: ES6, jQuery, HTML5, CSS3, Bootstrap.
8. DON'T bulk format files. This makes it very hard to trace the exact changes in case a revert is required.
9. DON'T do non-trivial refactoring. It becomes hard to track changes across commit and revert selectively when necessary.
10. DON'T change HTML class names or ids. It is hard to tell which is being directly referenced form the code.

• Linters.
• Unit tests.
• Effective manual testing process.

• Work items & Execution: v5 Release.
• Pipeline: Build, Deployment.
• Deployments: Staging, Production.
• Telemetry: Staging, Production.
• Cache: Staging & Production