Building automation for a music wiki
What I Learned While Opening Digging Music for translations, annotations, reviews, and criticism. Filling this wiki is not just a matter of translating lyrics. It also requires understanding cultural context, interpreting references, explaining metaphors, and writing in a consistent editorial tone.
To reduce that workload, I gradually designed an automation system using LLMs. The system went through several versions: simple translation, structured generation, context sharing, and finally a controllable pipeline where each output builds on the previous one.
This post is a development reflection on what I learned while designing that automation.
Version 1: simple translation automation
The first version was very primitive.
At the time, the Improving UI, UX, and the Lyrics Database in Digging Music structure was inefficient. Each lyric line had to exist as its own entity, so saving one song meant creating dozens of objects. This consumed time, database space, and server resources.
The automation itself only translated existing English lyrics line by line. It did not understand the song as a whole, and the output format was hard for humans to edit. Since the required output structure was complicated, it was also difficult to make the LLM follow the format reliably.
This version helped me confirm that automation was possible, but it was not yet a good system. It was closer to a script that reduced repetitive work than a real editorial pipeline.
Version 2: structured generation after database refactoring
After refactoring the database, automation accelerated.
I built a flow that crawled lyrics and annotations from Genius, stored them in a structured format, and generated translations, explanations, song introductions, and trivia. Because the database no longer required separate objects for every lyric line, the system could process more data with fewer resources.
However, this version still had a serious problem: each output was generated independently.
Translation, explanation, introduction, and trivia all had different prompts and different inputs. Translation only had translation context. The introduction only had background information. Annotation generation had its own separate input.
This created semantic conflicts.
For example, if a song used irony or metaphor, the translation might become too literal, the introduction might interpret the song in the opposite direction, and the annotation might focus on a completely different theme. One output could describe the song as sad, while another described it as a sweet love song.
The problem was not the model's writing ability. The problem was that each generation step lacked shared context.
Version 2 improved efficiency, but it did not solve consistency.
Version 2.5: sharing context through additional information
To solve the inconsistency problem, I added an additional_info field.
This was a human-written hint that summarized the song's theme, keywords, or interpretive direction before generation began. By giving the LLM a shared anchor, translations, annotations, introductions, and trivia started to point toward the same interpretation.
This reduced the problem of disconnected outputs.
But it was still not full automation. I had to understand the song first, write the additional information manually, and then let the LLM follow that direction. In other words, the system worked only when I already had enough knowledge to guide it.
The automation depended too much on human pre-interpretation.
Version 3: context-based explanation and controllable pipeline
Version 3 was the first version where I felt real automation might be possible.
After repeatedly completing documents by hand, I noticed that my own workflow had become more stable. I was no longer randomly moving between translation, annotation, introduction, and trivia. A natural sequence had emerged.
The flow looked like this:
- Generate a song introduction from crawled data and lyrics.
- Use that introduction as context for the full lyric translation.
- Use the same introduction as context for annotations.
- Combine the introduction and external data to generate trivia.
Once this pattern became clear, I could turn it into a linear pipeline:
generate_intro → generate_translation → generate_annotation → generate_behind
The key insight was that automation should not begin from a messy human process. First, the messy process has to be repeated manually until a stable routine emerges. Then that routine can be converted into functions.
With some prompt engineering and fine-tuning, the output became more stable. The writing style became closer to the wiki tone, and BBCode formatting could also be generated automatically.
This version was no longer just repetitive processing. It was an attempt to imitate a linearized thinking process.
Version 4: generating invisible information
The next version is still planned.
So far, the system mainly summarizes or recombines existing external data. Version 4 aims to generate explanations that are not directly available from scraped sources.
This includes cultural associations, historical interpretation, hidden irony, and multiple possible readings.