| Pages in topic: [1 2 3] > | Supervertaler Workbench is no longer actively developed Thread poster: CafeTran Trainer
|
|---|
Supervertaler Workbench is no longer actively developed.
Workbench still works, the source is still open, and the last release stays downloadable. But it is not receiving new features, and bug reports are unlikely to be acted on.
Source: https://supervertaler.com/workbench/
| | | | Li-Hsiang Hsu 
Frankryk
Local time: 06:46
uit Frans in Chinees
+ ...
A software like this is not maintenable, esp. if it is vibe coded by older models of Claude, which are much less capable than it is now. A viable approach would be to start over from scratch, if someone is keen on using this software.
In reality, I never managed to get it working. Has anyone else ever succeeded? @@
| | | | Michael Beijer
Verenigde Koninkryk
Local time: 05:46
Member
Nederlands
+ ...
| The future of Supervertaler Workbench (and the new Supervertaler for memoQ) | Aug 28 |
Li-Hsiang Hsu wrote:
A software like this is not maintenable, esp. if it is vibe coded by older models of Claude, which are much less capable than it is now. A viable approach would be to start over from scratch, if someone is keen on using this software.
In reality, I never managed to get it working. Has anyone else ever succeeded? @@
Hi Li-Hsiang,
I'm definitely not using older Claude models. I'm doing all coding with Opus 5 or Fable 5 at the moment, and I am constantly on the lookout for new models. However, your point about it not being maintainable is well taken. The main reason I have decided not to continue putting my time into Supervertaler Workbench (a free, open-source app that generates no income for me) is that Supervertaler for Trados (my paid Trados Studio plugin) is much more promising. The problem with developing something like Supervertaler Workbench, which is a full-blown CAT tool rather than a Trados Studio plugin, it is almost impossible to keep up with the myriad file formats that a CAT tool needs to be able to import and export reliably. Supervertaler for Trados, on the other hand, lets Trados Studio do the heavy lifting. This means users can be certain their exported file will match their imported file exactly in terms of formatting, tags, etc. This also lets me focus on the AI enhancements, improved terminology handling, web searches, etc., that Supervertaler for Trados offers.
Some highlights of what Supervertaler for Trados can do:
- https://docs.supervertaler.com/trados/mcp-server/ (this one is particularly interesting; it allows you to control Trados Studio 2024/2026 completely from the Claude or ChatGPT desktop chat app!)
- https://docs.supervertaler.com/trados/voice-commands/ (basic voice commands built into Trados Studio)
- https://docs.supervertaler.com/trados/supersearch/ (user can search project files, translation memories, termbases, and run web searches)
- https://docs.supervertaler.com/trados/termlens/ (my innovative term match viewer and SQLite-based termbase system)
- https://docs.supervertaler.com/trados/ai-assistant/super-memory/ (allows you to keep track of memory banks for specific projects or clients or whatever.)
I am currently also working on a memoQ plugin, tentatively called, rather unimaginatively, Supervertaler for memoQ. The memoQ plugin won't offer as many bells and whistles as the Trados variant because the Trados backend is much more powerful, but I hope to bring some of the magic of Supervertaler to memoQ users as well in the near future.
Incidentally, just because it isn't being actively developed right now doesn't mean the Supervertaler Workbench is dead. Not by a long shot. I just don't have time at the moment to do much work on it, but it might morph into something completely different. Who knows?
You mentioned that you never managed to get it working. Are you on Windows, Linux, or Mac? Which version did you try to get working? The Windows EXE or the PIP package? I've used it on many of my own projects. Actual, delivered jobs, so it is definitely functional.
Michael
[Edited at 2026-08-28 11:30 GMT]
[Edited at 2026-08-28 11:41 GMT]
| | | | CafeTran Trainer
Nederland
Member (2006)
uit Duits in Nederlands
+ ...
TOPIC STARTER
Li-Hsiang Hsu wrote:
A software like this is not maintenable, esp. if it is vibe coded by older models of Claude, which are much less capable than it is now. A viable approach would be to start over from scratch, if someone is keen on using this software.
In reality, I never managed to get it working. Has anyone else ever succeeded? @@
Yes, no problem at all. I actually created a lighter version of it because I felt it was bloated with voice recognition and the Java sidecar.
| | |
|
|
|
Li-Hsiang Hsu
Frankryk
Local time: 06:46
uit Frans in Chinees
+ ...
Hi Michael,
Thank you for taking your time to reply.
I tried it a few months ago but never managed to get it working. I didn't look into it any further. However, I have reviewed your code, and there are indeed some issues. I honestly think the best solution is to completely rewrite the software, using recent models of Claude, preferably models later than Sonnet 4.6.
Aside from a few flaws in the code, I suspect a major source of the issue is likely the int... See more Hi Michael,
Thank you for taking your time to reply.
I tried it a few months ago but never managed to get it working. I didn't look into it any further. However, I have reviewed your code, and there are indeed some issues. I honestly think the best solution is to completely rewrite the software, using recent models of Claude, preferably models later than Sonnet 4.6.
Aside from a few flaws in the code, I suspect a major source of the issue is likely the integration of the Okapi Framework (which is written in Java) into software written in Python. It seems to me that your parsers and segmenters are based on Okapi, aren't they? If my memory is correct. That conversion would normally involve subprocesses, which can sometimes cause issues. That’s just a guess, though; I can't confirm it.
As for your plugin, I haven't had a chance to try it out because I don't use Trados 2024 or later versions. I've found ways to avoid using them. Too bad I won't get the chance to test it.
Anyway, happy vibe coding! ▲ Collapse
| | | | Li-Hsiang Hsu
Frankryk
Local time: 06:46
uit Frans in Chinees
+ ...
| So Okapi could be the cause? | Aug 28 |
CafeTran Trainer wrote:
Li-Hsiang Hsu wrote:
A software like this is not maintenable, esp. if it is vibe coded by older models of Claude, which are much less capable than it is now. A viable approach would be to start over from scratch, if someone is keen on using this software.
In reality, I never managed to get it working. Has anyone else ever succeeded? @@
Yes, no problem at all. I actually created a lighter version of it because I felt it was bloated with voice recognition and the Java sidecar.
Maybe you are right. I try not to use Okapi because I write programmes either in Python or in JavaScript. I don't like involve subprocesses.
| | | | Michael Beijer
Verenigde Koninkryk
Local time: 05:46
Member
Nederlands
+ ...
Li-Hsiang Hsu wrote:
CafeTran Trainer wrote:
Li-Hsiang Hsu wrote:
A software like this is not maintenable, esp. if it is vibe coded by older models of Claude, which are much less capable than it is now. A viable approach would be to start over from scratch, if someone is keen on using this software.
In reality, I never managed to get it working. Has anyone else ever succeeded? @@
Yes, no problem at all. I actually created a lighter version of it because I felt it was bloated with voice recognition and the Java sidecar.
Maybe you are right. I try not to use Okapi because I write programmes either in Python or in JavaScript. I don't like involve subprocesses.
The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python. And the system actually works very well: it allows the user to import a Word document (.docx or .doc), as well as a large range of other file types, and export it reliably into a file with all the same formatting. However, for professional work, it simply was not reliable enough. It worked most of the time, but not always. If I use it in production on real projects, I need to know it will export correctly 100% of the time.
| | | | Michael Beijer
Verenigde Koninkryk
Local time: 05:46
Member
Nederlands
+ ...
|
|
|
Li-Hsiang Hsu
Frankryk
Local time: 06:46
uit Frans in Chinees
+ ...
Michael Beijer wrote:
Li-Hsiang Hsu wrote:
CafeTran Trainer wrote:
Li-Hsiang Hsu wrote:
A software like this is not maintenable, esp. if it is vibe coded by older models of Claude, which are much less capable than it is now. A viable approach would be to start over from scratch, if someone is keen on using this software.
In reality, I never managed to get it working. Has anyone else ever succeeded? @@
Yes, no problem at all. I actually created a lighter version of it because I felt it was bloated with voice recognition and the Java sidecar.
Maybe you are right. I try not to use Okapi because I write programmes either in Python or in JavaScript. I don't like involve subprocesses.
The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python. And the system actually works very well: it allows the user to import a Word document (.docx or .doc), as well as a large range of other file types, and export it reliably into a file with all the same formatting. However, for professional work, it simply was not reliable enough. It worked most of the time, but not always. If I use it in production on real projects, I need to know it will export correctly 100% of the time.
Yes, I agree. That software is more like a proof o concept rather than a real product. For production, you will have to find more robust solutions.
| | | | CafeTran Trainer
Nederland
Member (2006)
uit Duits in Nederlands
+ ...
TOPIC STARTER | How many filters does one need? | Aug 28 |
Michael Beijer wrote:
The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python.
That makes sense, Michael. But then again, how many filters do you really need? Usually, just the one for your next project! 😄
Python actually has very mature libraries for formats like MS Word (.docx), so you rarely have to build anything from scratch. The main advantage of sticking with pure Python is control and simplicity. Following the K.I.S.S. principle, I personally prefer to keep the stack fully Python-based whenever possible.
And for those rare cases where Python cannot parse an exotic file format, I import the files into Trados and do a round-trip via SDLXLIFF.
| | | | Dan Lucas
Verenigde Koninkryk
Local time: 05:46
Member (2014)
uit Japannees in Engels
Li-Hsiang Hsu wrote:
esp. if it is vibe coded by older models of Claude
If you take time to create a viable plan, split the plan into epics and tasks with reasonable granularity, implement one task at a time*, follow sensible coding practices, structure your projects properly, review the code carefully (either yourself or using a different LLM), and never give the LLM push/delete access to git, it's easy to build robust "vibe coded" projects.
Looking back at my projects over the past couple of years, my problems have nearly always been caused by poor design (typically characterized by a narrow perspective perspective at the start) rather than by poor LLM coding.
Obviously, somebody doing the "Build me the next Twitter, make no mistakes" meme will not get far.
Glad to hear that Michael is still beavering away on the plugin.
Regards,
Dan
*Many people use multiple agents working simultaneously and so on, but I'm old-fashioned and like to actually keep an eye on the coder while it works; maybe over time I will move to multi-agent workflows.
| | | | Li-Hsiang Hsu
Frankryk
Local time: 06:46
uit Frans in Chinees
+ ...
| Poor design, poor spec, poor review and testing | Aug 28 |
Dan Lucas wrote:
Li-Hsiang Hsu wrote:
esp. if it is vibe coded by older models of Claude
If you take time to create a viable plan, split the plan into epics and tasks with reasonable granularity, implement one task at a time*, follow sensible coding practices, structure your projects properly, review the code carefully (either yourself or using a different LLM), and never give the LLM push/delete access to git, it's easy to build robust "vibe coded" projects.
Looking back at my projects over the past couple of years, my problems have nearly always been caused by poor design (typically characterized by a narrow perspective perspective at the start) rather than by poor LLM coding.
Obviously, somebody doing the "Build me the next Twitter, make no mistakes" meme will not get far.
Glad to hear that Michael is still beavering away on the plugin.
Regards,
Dan
*Many people use multiple agents working simultaneously and so on, but I'm old-fashioned and like to actually keep an eye on the coder while it works; maybe over time I will move to multi-agent workflows.
I vibe code and review code. Poor design and poor spec do lead to bad Claude performance. Actually, if you don't give the right design and right spec, Claude (and its LLM fellows) will just follow a "Pareto" principle: making 20% of efforts to meet 80% of needs, so that the software works in 80% of cases. Claude and its LLM fellow are probabilist beings. They are rather comfortable with Pareto distributions.
| | |
|
|
|
Michael Beijer
Verenigde Koninkryk
Local time: 05:46
Member
Nederlands
+ ...
| As many as I can get my hands on! | Aug 28 |
CafeTran Trainer wrote:
Michael Beijer wrote:
The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python.
That makes sense, Michael. But then again, how many filters do you really need? Usually, just the one for your next project! 😄
Python actually has very mature libraries for formats like MS Word (.docx), so you rarely have to build anything from scratch. The main advantage of sticking with pure Python is control and simplicity. Following the K.I.S.S. principle, I personally prefer to keep the stack fully Python-based whenever possible.
And for those rare cases where Python cannot parse an exotic file format, I import the files into Trados and do a round-trip via SDLXLIFF.
Ha ha, how many file filters do I need? As many as I can get my hands on! It seems that almost daily a client will send me some yet another gigantic, multi-file job in a file format that pushes even Trados/memoQ to their limits. I don't think there is any realistic way to handle all these edge cases in Python alone. It's a fun challenge, but on a daily basis, I just need to get all these jobs done and out the door and ensure my client will receive them in the correct format. I can rely on Trados Studio to handle pretty much anything they throw at me.
| | | | Li-Hsiang Hsu
Frankryk
Local time: 06:46
uit Frans in Chinees
+ ...
| endnotes/footnotes, <w:sdt>, among others. | Aug 28 |
CafeTran Trainer wrote:
Michael Beijer wrote:
The reason why I decided to include Okapi is that Supervertaler Workbench could then make use of its extensive file filters, rather than have to code them from scratch in Python.
That makes sense, Michael. But then again, how many filters do you really need? Usually, just the one for your next project! 😄
Python actually has very mature libraries for formats like MS Word (.docx), so you rarely have to build anything from scratch. The main advantage of sticking with pure Python is control and simplicity. Following the K.I.S.S. principle, I personally prefer to keep the stack fully Python-based whenever possible.
And for those rare cases where Python cannot parse an exotic file format, I import the files into Trados and do a round-trip via SDLXLIFF.
I now need to switch from python-docx to lxml to parse docx documents from OOXML. Python libraries don't handle this.
| | | | Dan Lucas
Verenigde Koninkryk
Local time: 05:46
Member (2014)
uit Japannees in Engels
Li-Hsiang Hsu wrote:
Poor design and poor spec do lead to bad Claude performance.
That's what I just said - IF you follow some variant of SDD properly you should be fine. But we have no evidence that Michael has been guilty of not designing properly. So his code should be OK.
Your earlier comment implied that code generated by earlier generations of frontier LLMs isn't good enough. I don't agree. I think for the past eighteen months at least it has been (more than) sufficient for the kind of development that we are doing here.
I'm equally sure that there are fields of endeavor where LLMs just will not cut it, but here we are basically messing around with text processing. It is, literally, not rocket science.
Dan
| | | | | Pages in topic: [1 2 3] > | To report site rules violations or get help, contact a site moderator: You can also contact site staff by submitting a support request » Supervertaler Workbench is no longer actively developed | Pastey | Your smart companion app
Pastey is an innovative desktop application that bridges the gap between human expertise and artificial intelligence. With intuitive keyboard shortcuts, Pastey transforms your source text into AI-powered draft translations.
Find out more » |
| | TM-Town | Manage your TMs and Terms ... and boost your translation business
Are you ready for something fresh in the industry? TM-Town is a unique new site for you -- the freelance translator -- to store, manage and share translation memories (TMs) and glossaries...and potentially meet new clients on the basis of your prior work.
More info » |
|
| | | | X Sign in to your ProZ.com account... | | | | | |
Login to reply/comment 
