Project goal - jzohrab/lute GitHub Wiki

This documentation is deprecated/obsolete. Lute v2 has been replaced by Lute v3, a full Python rewrite. Please see the Lute v3 manual which includes notes on installation. If you have Lute v2, you can easily migrate to v3. Thank you!

The ultimate goal is for Lute, or a successor, to become as ubiquitous and natural for language learning as Anki is.

I believe that a Lute API/data backend could support other language tools.

My immediate concerns

Lute's a great tool, but I think that some things need to be changed for its long-term growth and stability.

The main two:

  • Simplify installation. For Docker users, it's pretty easy; for non-Docker, and Windows, not so much. Lute needs PHP, which isn't on most systems, and various PHP solutions (MAMP, WAMP, etc) have their own challenges.
  • Sustainability. I'm the only person working on Lute, which is a big exposure. If Lute were written in a more popular/interesting language, it might attract more developer support.

Changes required

Outside of the usual improvements and feature requests, I think the below areas of work will help Lute move towards the project goal.

In summary, the back end should be written in Python. The front end could be written using Flask, or any other framework, once the service level API is defined.

Reasons for rewrite:

  • Python is much more popular than PHP, so it will be easier to find team members
  • A Python project can be released as a .dmg for Mac, and ... something else for other platforms
  • Python has other language tools available, such as spaCy and stanza for language processing
  • Python has built-in support for Sqlite
  • potential for other things, like p2p networking
  • Lute relies on web dictionaries, and the rendering works just fine with html/css/js. I don't feel that using Python's Qt or Tkinter adds much benefit (I may be wrong about this)

Lute has many tests (unit and browser-level acceptance tests) that should facilitate any code transition. The browser-level acceptance tests do need to be beefed up in a few areas, as sanity checks.

1. Front end/back end proof of concept

The POC will help determine the frameworks, work out release and installation, etc, to work out any development/user issues. The POC only needs to be a toy CRUD app using Sqlite, JS, and Python, and then the release (and install) method should be finalized and tested.

The POC should also ensure that a Docker-based installation still works, for people who prefer that method.

If the POC isn't successful, there's no need to do rewrite the back end. Other work may still be beneficial.

2. Rewrite the back end to Python

This is obviously a big chunk of work. :-)

The back-end rewrite can't be released gradually, due to the nature of the user base. They've already installed PHP on their systems and set up their environment, I don't feel it's realistic to have them also install Python, and ensure the two systems are communicating correctly. The code needs to be complete, and the release and deployment method tested on multiple platforms. Then the upgrade path needs to be documented.

I've experimented a bit with this, and an easy way to work on this is using an Nginx reverse proxy, redirecting URLs to the new python project as parts are implemented.

⚠️ **GitHub.com Fallback** ⚠️