Kulasisi grew out of Aklish, a crowdsourced dictionary I built for Aklanon, my own language. This case study covers what changed when I tried to make the same idea work for any Philippine language, not just mine.
Aklish solved my problem. I could finally look up Aklanon words without asking my parents. But Aklanon isn’t special. The Philippines has around 175 languages, most in the same spot Aklanon was: spoken every day, barely present online. Wiktionary has almost nothing for most of them, because nobody who speaks them has a place to put that knowledge down. Aklish proved the model works for one language. Kulasisi is the attempt to make it work for many.
Why one dictionary wasn’t the point
The interesting part of Aklish was never “a dictionary for Aklanon.” It was the pattern underneath: give a community a place to contribute words, let voting sort good translations from bad ones, and the language gets a digital presence it didn’t have. That pattern doesn’t care which language you plug into it, so instead of cloning Aklish and swapping the word list, I rebuilt it around the idea that language is just another variable, not something wired into the code.
Rebuilding around a variable that used to be fixed
Aklish assumed Aklanon and English everywhere, in model fields, view logic, even template copy. That doesn’t scale to a platform meant to hold dozens of languages, each with its own contributors and quirks. So the backend became a Django REST Framework API with a languages app that everything else points back to: phrases, dictionary entries, translations, and votes all reference a language instead of assuming one. The frontend moved to Next.js, partly because a real API needed a real client, partly because I’d learned React since building Aklish. It was the minimum needed to stop hardcoding assumptions Aklish could get away with when it only had to be right about one language.
Splitting “translation” into phrasebook and dictionary
Aklish had one kind of contribution: a translation. That flattened two different things into one model. A phrase needs context and usage notes more than a part-of-speech tag; a dictionary entry needs the opposite. Kulasisi splits them into separate apps: phrases carry categories, source, and usage notes, dictionary entries carry part-of-speech tags, source, usage notes, and synonyms/antonyms. Both are still contributed and voted on the same way Aklish did it, but the data underneath is honest about what it’s holding.
Keeping what actually worked
Voting and reputation carried over almost unchanged, since Aklish taught me that’s the right way to keep quality up without moderators. The proofreader survived in spirit too: Aklish’s spell checker leaned on AklStemmer for Aklanon specifically, which doesn’t generalize, so Kulasisi’s proofreader plugs in per-language resources instead. And the games stayed, because people kept playing Aklish’s Wordle clone far more than they added new words. Contribution alone wasn’t enough to keep people around.
Where it actually stands
Kulasisi isn’t done. The core is there: CRUD for phrases and dictionary entries, auth, voting, reputation, the proofreader, games, branding. What’s still open is getting it in front of actual language communities, reliable deployment, and starter data, none of which matter until someone outside my own testing has used it. That’s a very different position from Aklish, which I could point to as a finished capstone project. Kulasisi is closer to infrastructure I’m still building than a product I’m shipping.
What generalizing actually taught me
Building Aklish taught me full-stack development. Building Kulasisi taught me that generalizing something personal is a different kind of hard. With Aklish, every decision had an obvious answer because I was the user. Kulasisi removes that shortcut: I don’t speak most of the languages it’s meant to serve, so I can’t rely on instinct for what an entry should look like in Hiligaynon versus Aklanon. I have to design for communities I’m not part of, which is harder than designing for myself.