Implement translation pipeline for non-Django projects

minvws / nl-kat-coordination

OpenKAT scans networks, finds vulnerabilities and creates accessible reports. It integrates the most widely used network tools and scanning software into a modular framework, accesses external databases such as shodan, and combines the information from all these sources into clear reports. It also includes lots of cat hair.

European Union Public License 1.2

127 stars 58 forks source link

Is your feature request related to a problem? Please describe. Currently, we have no ability to translate strings in e.g. octopoes and keiko. This is important though, since they contain natural text. For example, octopoes currently contains the strings which define findings, and keiko generates most of the text used for the report pdf's.

Describe the solution you'd like From what I gathered, GNU gettext is part of the Python standard library and is also used in Django. This seems like the premier candidate for our translation pipeline.

In addition, it would be nice if the community could help out with the actual translation part. We've considered using Weblate or Transifex in the past. It's a strain on the team to keep all translations up-to-date, especially just before a release.

Depending on how this goes, we may even consider expanding Weblate/gettext to the Sphinx docs.

Describe alternatives you've considered I'm not familiar with any other popular translation pipelines in open source projects. If somebody has a better idea be sure to let us know :)

We could also flip the order of priority, and implement Weblate/Transifex for Rocky/Django first. This could be a nice experiment to determine what we need from our translation pipeline.

This question is much wider than just the non-django parts of openkat. The fastapi part we could translate easily, (albeit there would be api changes to get the correct languages across to every consuming service). The bigger question is however related to external data being collected and used, Especially data that is very voluminous (think cve's) or data that changed rapidly (again, cve's).

For the internal findingTypes, we could probably commit to translating them ourselves when we add them, for the external findingTypes (snykfindings, cve's cwe, retirejs etc) this quickly becomes something we should not try ourselves (by hand) or should not pretend to guarantee we can provide.

Automated tooling to translate these findings, their reasons, POC's etc coud work, but since its highly technical language, and most likely very specific it might be a challenge to get this to work properly in translated form.

minvws / nl-kat-coordination

Implement translation pipeline for non-Django projects #1443