Progress Bar Is Not an API

When a CLI becomes useful, someone eventually tries to automate it. That is where a progress bar can quietly become a problem. For a person, this kind of output is helpful: Translating markdown files 12/40 30% docs/intro.md It tells me that the command is alive, how far it has moved, and which file it is working on. But when another system starts reading that same output, the progress bar stops being only a user interface. It becomes an accidental contract. That was the real problem behind one of the changes in Co-op Translator v0.20.0. The release added a Rich-powered CLI progress UI, but it also added structured translation events. At first, those may look like two separate improvements. They are really two surfaces for the same state: Rich output gives a person something readable, while structured events give integrations something stable. This article is about three things: First, why console output is tempting to parse. Second, how Co-op Translator separated the Rich UI from the event stream. Third, why that separation matters for CLI, Python API, MCP, and product integrations such as Localizeflow. The problem appears when logs become state Console output is written for people. When I run a translation command, I want a quick answer to a few practical questions: Is the command still running? Which stage is active? Which file is being processed? How much work is left? Did anything fail? A progress bar is good for that. It compresses the state of the run into something I can scan quickly. But a product integration needs a different kind of information. Imagine Localizeflow running Co-op Translator as part of a larger workflow. It does not only need to know that text was printed. It needs durable state: Which translation job started Which target language is active Which stage is running Which file completed Which file failed How many items are done Whether the run succeeded If all of that only exists inside console text, the integration has to parse human language