But the issue is that the standard parsers Dreamsavior uses are pretty bad (At least the ones I have and nobody was willing to provide me the newer ones, yet.), but they are required to be able to use the context system. (To be able to tag cells properly, unless you remake the entire system.)
So for now I can either try to include my properly working parser, with no guidance whatsoever, which basically guarantees that stuff will break because people don't have the experience what, where, can be translated how.
Or I use dreamsavior's parsers, have everything automatically tagged and formatted using a modified version of Reddo9999's tag system, but then some stuff breaks because the parser fucks up the VX Ace hash values.
What do you mean by context system?
For parsing, I had the same exact issue with the Translator++ parsers being sub-optimal for translation.
Sugoi in particular would often produce a result comparable to Google when parsed properly, but the Translator++ parsers would often break lines into very small chunks that made it impossible for Sugoi to tell what the context is. That meant going back to the raw source and manually rebuilding the untranslated string to get Sugoi to produce usable output because the parser broke it into unusable little chunks.
Instead of getting more into Translator++, like you have, I ran the other way and chose to only use it as an external tool instead of getting involved in its internals. The GPL license allows to be forked and distributed (minus the branding), but unless someone else is going to make it their full time project, then it is not really worth doing so because the project is under active development.
It already actually works almost flawlessly for MV though so if you want to play around with the current prototype, I'll send it to you.
Yes, please! If I can use it on an MV/MZ game to see how it works, then I can better understand how it should be working for VX Ace and can dive into the internals to see if it is a fixable issue or if the problem warrants a completely different approach.
You'd have to ask dazed that.
My Sugoi/Dictionary system is fully offline and produces more consistent results than DeepL at least.
What I meant was that I am not sure what your local hardware looks like.
Unless you train your own NMT models or otherwise update the sentencepieces model, Sugoi will never really improve on its own. The use of dictionaries to fix input/output is more of a band-aid fix than anything helping Sugoi improve its underlying quality. That drawback of being stale, not improving on its own over time, makes it worth looking into different approaches to translate text from Japanese or at least train your own models based upon the the model Sugoi uses or JPCrawl.
The other approaches available right now are to use Large Language Models, overt AI, which are a linear extension of NMT technology but can consider arbitrary context information when translating and are familiar with a wide range of topics, as opposed to being focused on translation. Basically, this is the GPT, and Meta's Large Language Model AI (LLaMA) however, it is now possible to run these AI models locally, fully offline just like Sugoi. The leaderboard I linked to lists several models able to work this way like Minstral8x7b, Tulu-2-DPO, and Yi-34B.
If your hardware is high-end enough to run Sugoi with GPU acceleration, then getting it to work with KoboldCPP and an LLM would likely also be doable so it might be worth doing a quality comparison check. There are also LoRAs for text-to-text models which are like extensions to a base AI model that allows that models to specialize in a particular task, like translation. I have not found any LoRAs suitable for JPN->ENG translation but I also have not looked very hard and, due to recent advances in the field, it is possible to train LoRAs on consumer grade hardware. But again, I am not sure what your local hardware situation looks like.
If it is low-end enough that running KoboldCPP is not really viable, then DeepL would be the better option to look into because DeepL is also allowing context and other AI-like features to be used with their API for free, although they might start charging for it later.
For your dictionaries, I am not sure what format they are in, but all of your current dictionaries should be forward-compatible with both KoboldCPP and DeepL meaning that you can benefit from creating them and the work that was put into them even if switching translation engines. If they are not forward compatible right now, then it would be trivial to write a parser to convert them into a format usable by DeepL or in a more generic spreadsheet format to allow them to be used with KoboldCPP or another LLM interface.