fkirc
feat: Add support for middlewares
I originally used the middleware to sanitize the translation keys. I’ve now done the sanitization directly in the typechat service. (see #280)
I’ll leave this here as a draft for now. Maybe a middleware will be needed in the future.
Given that unit-tests are currently failing and its status as a draft, I will leave this open for the time being. Please let me know in case if you are willing to finish it fully and fix the tests.
Sorry for the noise. The tests are now successful. I would suggest not merging the PR for the time being, because no middleware is currently needed. I would just leave the PR open, in case it’s needed in the future.
If you don’t think middleware makes sense, then you’re also welcome to close this PR.
Alright, let's keep the PR open until there is a pressing use case for it.
By the way, I would rather suggest to allow custom NodeJS-scripts as middleware, something like --middleware=some_node_script.js.
Then everyone could roll their own middleware without being dependent on me or someone else merging any middleware into the TypeScript-code.
Alright, let's keep the PR open until there is a pressing use case for it. By the way, I would rather suggest to allow custom NodeJS-scripts as middleware, something like
--middleware=some_node_script.js. Then everyone could roll their own middleware without being dependent on me or someone else merging any middleware into the TypeScript-code.
In fact this is already possible today if someone modifies attranslate's compiled JS-source; for example with some overwrite-script that replaces node_modules/attranslate/dist/core/invoke-translation-service.js with a patched version of invoke-translation-service.js.
It is part of the philosophy of attranslate to make such modifications easily possible, by having well-readable code and not using any obfuscation during TypeScript-compilation.
But like I said, I would be open to merge a middle-ware feature if there is a specific use case for it.