Welcome to The Markup, where we use investigative reporting, data analysis, and software engineering to challenge technology to serve the public good. Sign up for Klaxon, a newsletter that delivers our stories and tools directly to your inbox.

Picture this: you’re me, Miles, Full Stack Operations Engineer at The Markup. It’s the day of a major publication milestone—our first Arabic-language article. The team has spent a couple of days frantically jury-rigging support for right-to-left text in articles, and you think you were successful. 

Then, at 10:24 a.m., you get a message from the Editor in Chief. 

“Ahhhh I just realized that I can’t put the Arabic translation on the homepage because it’s not oriented correctly.”

Seven minutes later another colleague replies, “not to open a can of worms, but the Series page has the same issue.”

You know you’re in for another long day. 

Let’s back up. About a month ago, a team of incredible journalists at The Markup published an article on the byzantine world of Instagram censorship. The article grew from claims of censorship following the war in Gaza, so editors decided to publish an Arabic translation of the original English article. Our developers, myself and Visualization Engineer Joel Eastwood, set about making sure our publishing system could handle the translated text. Unlike English, which is written to be read left-to-right, Arabic is read right-to-left. (Hebrew and Urdu are other major modern right-to-left languages.) In order to be correctly formatted on our website, Arabic text needs to flow in the opposite direction than the site was originally designed for—in other words, we needed to overwrite our publishing system’s basic assumptions. 

The Markup uses a highly customized, self-hosted version of WordPress, a widely used content management system. This level of control is double-edged: on the one hand our system is exactly tailored to our needs. On the other, we can’t use pre-made solutions to problems just like this one, which many publishers have encountered before.

Upon jumping into our code, we quickly realized that just switching the text alignment from left-aligned to right-aligned wasn’t going to cut it—not only did it ignore the headline, photo captions, and bullets in lists, it didn’t even properly right-align all our paragraph text. Instead, we added an article-level toggle, indicating whether the article was written right-to-left or left-to-right. Using that toggle, we right-aligned paragraphs, bulleted lists, article credits, headlines, pull quotes, and other non-standard pieces of articles. Still, much of our early approach was indiscriminate: applying right-to-left styles to everything in an article.

When we previewed these changes, we noticed a host of unintended effects. The Markup has many article elements with unchanging text. This process of using static text is called ‘hard-coding’, and is among the simplest and least flexible software development techniques. Among the hard-coded elements were the donation widget, and many of the headings and filler text throughout an article, like the “By” and “and” in “By Natasha Uzcátegui-Liggett and Tomas Apodaca” at the top of the article. 

So we fixed that. Then, an editor WHO SHALL REMAIN NAMELESS asked if we could make it such that the ‘Credits’ header at the bottom of the page could be replaced with Arabic text for this one article.

As shepherd of our little codebase, I had to put my foot down. This is what’s called “scope creep.” It’s when a fairly simple change balloons into a much more complicated set of features. Up until this point, the codebase wasn’t aware we were dealing with Arabic, specifically. All the software knew was that sometimes articles were left-aligned, and sometimes they were right-aligned. 

This was deliberate. In an ideal world, we’d handle translations with a robust localization system—the kind that allows editors to choose a language from a drop-down and have the entire article, credits and all, appear in that language. Given our timeframe, we went with the next best thing: the article-level alignment toggle. We could develop it fairly quickly and include it in future localization work. Hard-coding Arabic text into the article would make our system very brittle, and introduce code we’d just have to rip out later. 

So we deployed the right-to-left work and scheduled the article to publish the next day. The following morning, we realized a critical blind spot in our approach. We had focused exclusively on right-to-left text in articles, overlooking all the other places it would appear, and pushed code out faster than we could thoroughly test it. So we pulled together another release, fixing alignment on the homepage and series pages, among other issues. 

This is neither ideal nor uncommon. It’s largely how humans make things: We see a problem, we decide how we’re going to fix it, and we generally don’t think much further ahead. When new problems come up, we end up retrofitting or rebuilding what we made. 

At The Markup, we report on tech companies whose algorithms and products weren’t designed for the needs of marginalized people, and subsequently fail to meet those needs, even after being retrofitted to suit. For example, last August, The Markup reporter Tara García Mathewson reported on AI detection tools falsely suggesting that international students had plagiarized their work. 

Yet last week, I was engaged in the very practices that lead to the failures we report on. The Markup’s software was designed exclusively for English, and we patched on a less ideal solution because we didn’t have the time to rebuild from the ground up. 

We strongly believe that getting this information out there as accessibly as possible was worth it. It’s a priority at The Markup to build our ability to publish in languages other than English, including languages like Arabic that read differently from English, regardless of the product lift. In addition to the Arabic Instagram story, we recently published a Vietnamese translation of an article on misinformation and will continue translating articles into the languages that give them the greatest impact. That’s why we hope to build out a true localization system, allowing us to better reach communities that are chronically underserved by western software products. 

More broadly, we will continue to practice proactive software development—looking early in the product design cycle for diverse perspectives or needs, and folding them into designs before anyone asks for them. Proactive development requires a mental shift, an intentional stretching of the problem you’re trying to solve from “what’s right in front of me” to “all the ways that people might use this.” Fundamentally, it’s the practice of empathy in the context of product design. 

When it comes to software development, there are always trade offs and compromises. A strong product value system can help guide development priorities, as can a healthy dose of humor. It won’t always be perfect, but it’s almost always workable.