In a some KDE applications we have use cases, where using "trans" as a subprocess could provide nice useability to the user. Examples are a vocabulary trainer and an articulation training application in our educational module.
Right now, we are using current CLI and parse the output of the trans requests, which is IMO not a very future proof way, because the layout of the result printing cannot really be assumed to be stable.
What I have in mind is an option like "-o json" where the result is not nicely printed but is provided by a serialized json object, which then can easily be used by other processes. An example of how that could like is e.g. "journalctl -o json".
In a perfect word there would also be a basic format stability guarantee or otherwise a version scheme with which I could provide parsers for different versions of the CLI API.
In a some KDE applications we have use cases, where using "trans" as a subprocess could provide nice useability to the user. Examples are a vocabulary trainer and an articulation training application in our educational module. Right now, we are using current CLI and parse the output of the trans requests, which is IMO not a very future proof way, because the layout of the result printing cannot really be assumed to be stable. What I have in mind is an option like "-o json" where the result is not nicely printed but is provided by a serialized json object, which then can easily be used by other processes. An example of how that could like is e.g. "journalctl -o json". In a perfect word there would also be a basic format stability guarantee or otherwise a version scheme with which I could provide parsers for different versions of the CLI API.