What’s stopping you from your moon mission of getting seamless continuous software localization? It’s often the lack of a “lunar module,” that one piece of software—middleware—that makes every mission successful. Software developers know all too well the key problem of software integration: everything is going smoothly, and then boom! Houston, we have a problem. The new code has been compiled, the assigned task has been completed and all that is left is the integration of the source code into the overall project. That’s when the challenge arises. To prevent a long development project from failing due to compatibility problems, many teams choose continuous integration, which means that developers integrate code into a shared repository (for example, GitHub), preferably several times a day; each check-in is verified to fix bugs more quickly, improve software quality, reduce validation and release times. Things get more challenging when we add localization to the workflow. Nowadays, experts and practitioners agree: Software localization should be fully integrated into software development projects to speed up the release of new updates in various languages. In other words: we want the release of the original software and of the localized versions to happen (almost) simultaneously. Therefore, the development and the localization teams need to be in sync at every single step of the project. But software localization comes with its own challenges: sometimes localizers are provided with new strings and updates without any context, or version tracking gets messy. Workflow automation then becomes a must. Continuous Software Localization: The Ideal Workflow For continuous integration and localization to be synchronized,  it’s necessary to implement some sort of lunar module to be detached from the development team, set things straight in another locale and get back with all the stuff to the mothership. So, what should a lunar module for continuous software localization look like?  First, let’s see what a typical localization workflow in such a setting could be. On the one end of the workflow there is a repository, a distributed version control, typically a Git repository (GitHub, BitBucket, GitLab and so on) containing the codebase. On the other end, there is the translation management system, the space where the translation team localizes the software strings. The lunar module in question that makes sure that the localization team can receive the localization jobs is called a middleware. Simply put, it’s a software, placed between the Git repository and the TMS, that can: pull the files from a version control system – like Git, for example – and consolidate them; filter the strings to be translated and distribute them directly to the localization teams; collect it all, once the work is completed, and push it back to where it came from.  Continuous Software Localization: A Middleware’s Essential Features  Let’s now take a look at the essential features of Beebox, Wordbee’s middleware, the excursion module that helps you move between the different stages of a software localization project. Privacy and security – A software repository like Git is hosted on your company’s server or in the cloud, and it is protected by users’ credential. The Wordbee translation management system, on the other hand, is available in SaaS mode and hosted on the Microsoft Azure cloud computing platform. The Beebox middleware can be either implemented on your company’s server or you can opt for the SaaS version, again hosted in Microsoft Azure. A localization dashboard – Project data is always at hand: the number of source files, the jobs still open and/or completed, the number of words per translation job, the status of the strings sent for translations, the progress of the project and more. Automatic creation of translation jobs – With the Beebox and Wordbee translation management system combined, you can automate job creation and assignment to a specific vendor. Alternatively, you can offer the job to a selected group of vendors and the first vendor to respond will receive it. Bundling option –  You can choose whether to send to your translation team only the strings requiring translation or the whole file: with this second option, translators will be able to have more context and the new strings will be flagged so that the localization team will immediately see which content needs to be processed. Machine translation configuration  – When the strings are retrieved from the Git repository, you can configure the MT system of your choice so that translators will receive only the chunks of content to be post-edited. Specific folder/subfolder setup – You can specify the folders containing the files to be translated as well as the folders and subfolders where the translated content is stored. You can also choose whether to change the names of translated files, for examples, by appending the language codes. Text extraction rules –  You can select any type of files in your Git repository for localization, whether .txt files, .po files, YAML, XML, HTML or MS Word files. Live Preview –  Translators can preview the screens of a web-based application in real time through a proxy server. This in-context translation feature is also useful for reviewers and testers to smoke test the software.