> /home/jd
ES / EN

Why I Retired Automatic Translation with Ollama

A retrospective on a local translator that worked as a prototype but failed to meet this portfolio's standards for accuracy and editorial consistency.

Local translation prototype built with Ollama

During an early stage of this portfolio, I built a local translator with Ollama, Node.js, and an 8B Llama 3 model. The goal was appealing: write in Spanish, produce an English version without sending drafts to a third party, and avoid per-token fees.

The prototype worked in the most basic sense. It generated files, preserved part of their structure, and reduced the time needed to obtain a first pass. It did not, however, solve the important problem. A translation that looks correct while altering a path, omitting an idea, or reversing an argument does not improve an editorial workflow.

I therefore removed Ollama and automatic translation from the active process. This note preserves the experiment’s architecture, the failures I observed, and the decision that followed.

What I Was Trying to Solve

A cloud API introduces connectivity requirements, credential management, usage costs, and a decision about what information to share. Local inference offered operational privacy and freedom to iterate.

The hypothesis was that sufficiently careful automation could generate English counterparts and keep them synchronized. The experiment combined:

  • frontmatter separation with gray-matter;
  • two strategies selected by content tags;
  • image masking;
  • an MD5 hash cache;
  • a dictionary of fixed translations;
  • experimental Git-hook integration.

Prototype Architecture

Technical Strategy

Notes tagged technical were processed through a Markdown AST with temperature 0.1 and node-level caching. The goal was to reduce variation and prevent the model from rewriting code or structure.

Personal Strategy

Notes tagged personal were divided into larger chunks and used temperature 0.7 without caching. The intention was to preserve the rhythm of essays and poems more effectively.

Masking

Markdown images were temporarily replaced with opaque tokens:

Text
![Diagram](/images/architecture.png)
→ __IMG_0__

After inference, the script restored the original value. This reduced one class of failure, but did not protect every sensitive Markdown or MDX element.

Cache and Overrides

Each technical node received a hash. If it had not changed, the system reused its translation. An overrides file fixed names such as Dotfiles, Silakka54, and Loutaif Connect.

These layers made the prototype more efficient, but also increased its complexity without solving the underlying semantic-quality problem.

What Failed

Fluency Without Fidelity

The most serious risk was a perfectly readable sentence that communicated something else. In one personal note, the English draft claimed that we engage with a machine so it can think for us, even though the Spanish source argued precisely the opposite.

Modified Literal Data

Later review found paths with missing underscores, translated filename-template tokens, altered names, and code comments left in Spanish. In technical documentation, any of these defects can turn a guide into an invalid instruction.

Omissions

Some translations dropped paragraphs or complete troubleshooting sections. The result looked finished because it contained no obvious error markers, but it no longer represented the source.

Automation Inside Git

The experimental hook combined translation, staging, and committing. It could overwrite manual corrections or include files outside the intended scope. A version-control operation should not transform editorial content.

Review Cost

The promise was to save time. In practice, reviewing an unreliable translation required comparing every sentence, path, and code block. For long notes, repairing the draft could require more attention than producing a rigorous English adaptation from the outset.

Current Decision

The active workflow is deliberately editorial:

  1. The Spanish note is written and approved as the authorial source.
  2. The English version is prepared manually or with assistance from a capable AI using the complete source.
  3. Technical notes prioritize terminology, code, and reproducibility.
  4. Personal notes prioritize natural English without losing voice, intent, or deliberate ambiguity.
  5. Both versions are compared before translationStatus: reviewed is assigned.
  6. The build publishes approved versions only and never translates content.

The generated and reviewed metadata remain useful, but now describe the file’s editorial state rather than a stage in an automatic translation pipeline.

Performance Was a Secondary Optimization

On my Hackintosh, the 8B model ran primarily on the CPU and reached approximately 11 tokens per second. That measurement was sufficient for experimentation, but ultimately irrelevant to the decision. Fast or private output does not compensate for a mediocre translation that must be reconstructed manually.

Historical diagram of the technical and personal pipelines

Conclusion

Retiring an automation is also an engineering decision. The prototype provided useful experience with masking, ASTs, caching, and local inference, but its output did not meet the standard required of a professional calling card.

The lesson is not that every AI is unsuitable for translation. It is that the tool must be equal to the content and remain subordinate to editorial judgment. In this portfolio, technical accuracy and expressive naturalness matter more than being able to say that the process is automated.