Eints replacement

eints-replacement.md

Motivation

Eints has been written years ago, and it is showing.

• The interface feels dated, and there are several feature-requests related to it.
• The codebase is very hard to deal with. It was written in a Python style that is unusual (really too much OO, not much use of Pythonic, more a C++-style of writing, etc).
• The backend of eints is consuming a lot (500+ MiB) of memory, which costs a lot monthly.

Also, in its core, eints is not all that complex. So I was wondering .. could we bring this to 2024?

Replacement

Features

Client-side features:

• Quickly see all strings outdated or not translated
• See related strings
• Being able to filter the list of strings to translate
• See history
• Validate {G} and {P}
• Support cases per language

Server-side features:

• Validate {G} and {P}
• Validate cases
• Import / export to .txt format

Storage

The storage is, as with the wiki and BaNaNaS, done on GitHub. We store there JSON files per project per language.

In this JSON we store the translations and their (short) history. It is a bulky file, ~1MB per translation (uncompressed).

Each translation also has a date (or version) of what the english string was it translated. This to track whether the translation is in sync with the english string.

Frontend

The frontend would be a React frontend. After login, it fetches the JSON from GitHub, calculates what is translated and what is not, and asks the user to start translating. This is done per translation.

Client-side already does string validation and all that stuff. Additionally, the client is aware of cases per language, and represents that in the right way.

When a translation is done, the string it send to the backend, which also validates it, and keeps it in memory for 5 minutes or so. After that time, it is committed to GitHub.

To keep clients up-to-date in the time between, the backend can also be requested for a "delta" of the language: these are strings that are pending and not yet committed.

Backend

A very lightweight component:

• Handles login flow
• Queues changes
• Sends (in batch) changes to GitHub

Pretty much like the wiki or BaNaNaS

Import / export

Via a GitHub Workflow, the JSON file is analyzed and transformed into a .txt for OpenTTD.

Reversely, OpenTTD's english.txt is read, and converted into a JSON.

It is important that how this new translator tool deals with changes in OpenTTD's code-base should be very predictable. As in, https://github.com/OpenTTD/OpenTTD/blob/master/docs/eints.md should still remain true.

• English touch-ups should mark translations of that string as outdated.
• English parameter changes should invalidate the translation. They will no longer show up in the .txt, but are still shown in the interface.
• When an English STR is removed, so do the translations.
• When an English STR is added, so do they get added in the translations.
• Reordering the English STRs should have no effect on the translations (other than that they reorder too).
• The translator tool always wins when it comes to translations. Changing them in OpenTTD is pointless.

More than one repo

This new tool should be quick and easy to deploy for other repositories, like forks, steam-strings, OpenSFX, etc. Ideally it is the same backend & frontend, but some list or whatever where to push/pull from. Possibly a seperate JSON file in the GitHub repository for this, just listing them out.

Backwards compatible

https://translator.openttd.org/language-list should remain in the format it is.