a Python workflow for creating blended-language books
Prismatext's MVP, dubbed Gringlish, was the first iteration of the blended-language concept. It reduced the time to create a blended-language book by 99%, but it still had limitations: output was limited to one variant per language, it was still comparatively slow, efforts to update the books were divorced from automation, and the system was not scalable. Bullwinkle set out, first and foremost, to offer a greater number of variants per language: from 1 to 27. It also reduced further the time to create by another 90%, allowed for nuanced control of translations, and can scale to any language pair.
Before writing any code, it's important to understand how Bullwinkle relates to the apps and services it interacts with.
One of the luxuries of having an MVP like Gringlish was that it helped me identify key issues that needed to be addressed in the next iteration. Bullwinkle's specification document was, essentially, a merge of these issues as well as customer feedback we'd accrued over the previous years. From these documents came detailed wireframes, which formed the outline of the code that needed to be written. (These wireframes also came in handy when we submitted our patent application in 2023.) Once the path forward was clear, I began writing the first lines of code in what became the blended language codebase.
We built our own e-reader in part because our need for rich footnotes wasn't available in other e-readers.
This was the most daunting project of my professional career. As the sole developer, it was left to me to determine the best way forward, how to handle setbacks, and how to communicate the progress to the rest of the team. I was fortunate in being able to solicit feedback from more experienced developers for specific aspects of the logic, and I learned a great deal about perseverance and the importance of a good support network.