How I designed Weaver as a local-first translation workspace instead of an AI chat wrapper
Weaver was built as a local-first translation workspace for Japanese light novels, not as a thin wrapper around an LLM API.
Jun 20, 2026·11 min read·weaver, local-first, ai-translation, translation-workflows, translation-memory
How I designed Weaver as a local-first translation workspace instead of an AI chat wrapper
When I started building Weaver, I was not trying to build “another AI translator.” The actual problem was not generating a translation for a single paragraph. Modern language models can already do that reasonably well. The harder problem was managing translation as a long-running workflow across an entire light novel: dozens of chapters, recurring terminology, character-specific phrasing, revision passes, and repeated AI-assisted retranslation without losing context.
That distinction shaped the architecture of the project.
Weaver is a local-first AI translation workspace for Japanese light novels. It combines chapter management, glossary systems, character databases, translation memory, multi-provider AI support, and batch translation workflows in one environment. The goal is not to replace human review with a single “translate” button, but to provide a system where AI-assisted translation can be managed as a structured project rather than as a collection of disconnected prompts.
This post explains why I approached Weaver as a translation workspace instead of an AI chat interface, and what architectural decisions follow from that choice.
The problem was not translation quality in isolation
The simplest way to build an AI translation tool is straightforward:
paste source text into a prompt box
send it to a model
display the result
optionally allow the user to retry with a different prompt
That works well enough for short text. It breaks down quickly for long-form narrative translation.
Light novel translation has a different set of requirements than one-off text generation:
terms need to remain consistent across chapters and volumes
character names, aliases, and speaking styles need to persist over time
the translator often needs to revisit older chapters after updating terminology decisions
repeated phrases should not be translated from scratch every time
project context needs to survive across many translation sessions, not just one prompt window
AI output needs to fit into an editing and export workflow rather than stop at “the model responded”
If those constraints are ignored, the workflow becomes fragile. The model may generate acceptable sentences locally, but the project as a whole becomes inconsistent. Terminology drifts, chapter context gets lost, and revision work becomes mostly manual cleanup.
That is why Weaver was not designed around a prompt box. It was designed around the state of the translation project itself.
I treated translation as project state, not as chat history
The most important design decision in Weaver was deciding what the primary unit of the system should be.
On this page
In a generic AI app, the main object is usually a conversation or a prompt-response pair. In Weaver, the main object is the translation project. More specifically, the system is structured around novels, volumes, chapters, and the translation resources attached to them.
That sounds like a small distinction, but it changes the architecture significantly.
If the core object is a prompt, the system mostly needs to store messages and generated output. If the core object is a translation project, the system needs to preserve a much richer set of relationships:
source chapters and their metadata
translated outputs and their revision history
glossary terms and terminology constraints
character records and contextual notes
reusable translation memory entries
provider/model settings used for different translation runs
export-ready chapter states
workflow state for chapters that are draft, reviewed, revised, or ready to publish
In other words, the product needs to behave less like a chat client and more like a project workspace with AI features embedded inside it.
Why local-first mattered
I chose a local-first approach for Weaver because the translation workflow itself benefits from being treated like a persistent desktop-style workspace rather than a purely cloud-mediated prompt interface.
There were three reasons this mattered.
1. Translation projects are long-lived and state-heavy
A light novel translation is not a short interaction. It is a project that can span multiple volumes, many chapters, and repeated revision cycles. That means the application needs to preserve state well: not just the latest model response, but the supporting resources and decisions around that response.
A local-first architecture makes that workflow feel closer to a personal editing environment than to a transient chat session. The project files, glossary state, translation memory, and chapter records belong to the workspace itself rather than being treated as temporary context assembled only when the user opens a page.
2. The valuable data is not only the generated output
In a translation workflow, some of the most important assets are not the model outputs themselves but the resources that make later outputs better:
glossary entries built up over time
character-specific notes and naming conventions
reusable translation memory pairs
decisions about how certain recurring terms should be rendered
chapter-level context accumulated across the project
Those assets become more useful the longer the project runs. A local-first model makes it natural to treat them as first-class project resources rather than ephemeral prompt attachments.
3. Workflow control matters more than “instant AI”
A translation workspace needs to support more than just generation. It needs to support reviewing, refining, retranslating, exporting, and comparing outputs. That means the user should be able to decide when to run a provider, when to reuse a glossary, when to override a translation memory match, and when to regenerate a section with updated context.
That kind of control is easier to design when the application is built around a persistent local workspace rather than around a remote chat loop.
The architecture Weaver needed
Once I decided that Weaver was a translation workspace instead of an AI chat wrapper, the architecture became clearer. The system needed to separate at least five concerns:
project structure
Novels, volumes, chapters, and chapter metadata.
translation resources
Glossaries, character databases, and translation memory.
review and revision state
Draft outputs, refined outputs, retranslations, and chapter progression through the workflow.
export and downstream usage
Converting completed translation outputs into forms that can be edited, reviewed, or published outside the app.
That decomposition matters because each part of the workflow changes at a different rate. A user may update glossary entries without retranslating immediately. They may re-run one chapter with a different provider while keeping the same project structure. They may export a volume after a review pass without changing translation memory at all.
Treating all of those concerns as one giant “AI translation request” would make the system brittle. Separating them makes it easier to reason about what changed and what should be recomputed.
The core workflow I designed around
At a high level, Weaver’s translation flow can be thought of as a loop rather than a single request:
import or create a translation project
organize content into novels, volumes, and chapters
attach glossary entries, character notes, and existing translation memory
run AI-assisted translation on selected chapters or batches
review the generated output in project context
refine terminology, update resources, or re-run translation where needed
store the resulting outputs and project state locally
export the completed work when the chapter or volume is ready
That loop is important because translation quality often improves through repeated passes, not through one perfect prompt. A good translation system should make iteration cheaper, not assume that the first model response is final.
Why translation memory and glossaries are architectural features, not optional extras
One of the easiest mistakes in AI product design is to treat glossary support or translation memory as “nice-to-have add-ons” after the main generation flow already exists.
For Weaver, they are part of the architecture, not polish.
Translation memory changes the cost of repetition
Light novels contain recurring phrases, repeated descriptions, repeated honorific patterns, and stable character terminology. Re-translating those fragments from scratch every time is both inefficient and risky, because it creates inconsistency even when the model is strong.
A translation memory system allows the workspace to reuse previous decisions instead of relying on the model to rediscover them. More importantly, it shifts the product from “generate every sentence independently” to “build cumulative consistency over time.”
Glossaries constrain the output space
A glossary is not only a convenience for translators. It is also a mechanism for narrowing the translation problem. Once key terms, proper nouns, title conventions, or domain-specific vocabulary are defined, the system can inject that knowledge into later translation runs and reduce drift across chapters.
This matters especially in long-form fiction, where terminology consistency is often more important than sentence-level elegance in any one isolated paragraph.
Character databases preserve narrative context
Character information is another form of reusable translation context. Names, aliases, speech style notes, relationship context, or recurring descriptive patterns all influence how a chapter should be translated. Storing that information as structured project context is more reliable than hoping the model remembers it from earlier prompts.
Multi-provider support was a workflow decision, not a feature checklist item
Weaver supports multiple AI providers because different stages of the workflow may benefit from different models or cost/performance trade-offs. That does not mean “more providers” is automatically better. It means the system should not force the entire translation workflow to depend on one model path.
From a workflow perspective, provider abstraction matters for a few reasons:
one model may be better for a first-pass translation, another for refinement
prompt behavior and style may vary across providers
long-form projects benefit from being able to retry or compare outputs without restructuring the whole workspace
model quality, pricing, or availability can change over time
If the translation system is tightly coupled to one provider, changing that provider later becomes an architectural migration. If provider support is treated as a translation execution layer inside the workspace, experimentation becomes much easier.
The hardest part was not generation. It was preserving coherence.
The most important lesson from building Weaver is that long-form AI translation is mostly a systems problem.
The language model can already generate text. That is not the scarce part anymore. The scarce part is building a workflow that preserves coherence across the entire book:
chapter context needs to remain connected
translation decisions need to be reusable
terminology changes need to propagate cleanly
revision passes need to be manageable
outputs need to be reviewable in context
project state needs to survive across many sessions
Without those pieces, an AI translator is just a fast way to create inconsistent drafts. With those pieces, the model becomes one component inside a much more reliable translation workflow.
What I would do again
If I were redesigning Weaver from scratch, I would still start from the same principle:
design the translation workspace first, then decide where the LLM fits inside it.
That means:
define the project model before designing prompts
decide how glossary, character, and translation memory data will be stored before wiring providers
treat translation as an iterative workflow instead of a single API request
make review, refinement, and export first-class parts of the product
keep the generated text attached to persistent project state rather than to disposable chat history
That sequence matters because it keeps the product focused on the real problem: managing long-form translation work, not just generating text.
Closing thoughts
Weaver exists because translating a light novel is not the same problem as translating a paragraph in a chat box. The challenge is not only producing language output, but building a workspace that can preserve context, reuse prior decisions, and keep a project coherent over hundreds of pages.
That is why I did not build Weaver as an AI chat wrapper. I built it as a translation workspace with AI embedded into the workflow.
The difference is subtle at the UI level, but significant at the system level. A chat wrapper optimizes for generating a response. A translation workspace optimizes for carrying a project from the first chapter to the last without losing structure, consistency, or control.