I got very excited when I first read the term LangOps in a recent article in no less than Fortune Magazine. Despite the fact that it isn’t yet well defined and could mean different things to the beholder, I think we can say that LangOps includes software that automates repetitive language processing tasks and facilitates the speed at which translations for digital media, particularly software, are delivered.
This could involve documentation automation, marketing materials, and more, with different automation and processing accelerators used for various roles, considering the content creator to the translator. The emphasis is on reducing the time to deliver translations that are integrated into the creation of content or assets that need the translation.
The automation and processing of LangOps can include file handling, measuring and focusing on small changes that happen with iterative development, the application of machine translation, translation memories, translation workflows, and more. Without systems, localization becomes a boat anchor that drags down the pace of product development and releases and ties up expensive personnel doing things that machines can do more efficiently.
The term LangOps borrows from the development-oriented term DevOps. DevOps combines development (Dev – specifically relating to software) and operations (Ops) to unite people, processes, and technology in application planning, development, delivery, and operations. DevOps enables coordination and collaboration between formerly siloed roles like development, IT operations, quality engineering, and security. It’s not a particularly tightly defined practice, and we can extrapolate LangOps to be similarly broad. But in my mind, it’s a long overdue bit of terminology which adds to our industry efforts in ways that established broader terms such as Localization or Internationalization fail to specify. A modern development organization supporting many languages and locale requirements should require automation systems that help keep language professionals working in step with creators but also includes planning, development, collaboration, QA, translation providers, and language assets.
For Lingoport, we deliver to software development teams, ultimately solving problems that cause a gap between localization and development teams and missions. This ranges from software that supports continuous internationalization, localization, and related QA.
The promise of the internet was always massive access to information, markets, and ultimately users. Inhibitors are technology propagation and language, and usability. Most developers get excited about that, but it’s all the manual handling, delays, and divergence for localization that can cause trouble.
What LangOps likely means to the developer
There’s a long history of development seeming to consider localization as an afterthought, or at least as a task that is done later and a reactive distraction, always running behind release progress. There are good reasons for those localization headwinds. When developers consider various quality attributes and functional delivery, they are used to built-in systems that minimize manual work and give immediate feedback during their commits and pull requests (for the uninitiated, think of this as when you save your work and then have your peers look it over).
Localization obstacles to continuous development
- Lag on continuous delivery
- Issues with minimums impacting small or last-minute string changes
- “File nanny” operations
- Variant file formats, locale designations
- Synchronizing files for various languages and updates
- Bug fixing on i18n issues
- Seeing results quickly and not after a translation delay
- Need for actions on commit or pull request
- Callable from Slack or Teams – being in the developer’s world
LangOps speaks to the development organization differently than the LSP or translator.
While the translator may consider that LangOps resides in the TMS workflow and workbenches that help them get their work done and organize translation people and assets, software developers have no window into the workings of a TMS and probably shouldn’t anyway.
For a development organization, LangOps is all about automation, automatic checks, and seeing results. For example, Lingoport’s Globalyzer and Localyzer provide all these integrated capabilities:
- Checking for i18n issues that will inhibit localization on commits and pull requests lets the developer directly work with the code they are responsible for and is fresh in their minds.
- Applying initial translation during the design/prototyping phase in FIGMA
- Leveraging any prior translations prototyped in tools such as FIGMA
- Checking the formatting of localization files and locales and providing transforms as needed automatically (i.e., JSON, YAML)
- Providing immediate pseudo-localized files so they can see how the U/I will present in other locales and languages
- Providing immediate machine translations for further visual inspection
- Sending files for translation
- Automatically providing context to the translator
- Receiving and synchronizing files as they come back to automatically handle any last-minute changes
- Automatically mapping “creative” locale codes that may have been particular to any one development team and stray from ISO standards.
- Adding locales
- Launching and managing i18n, pseudo-localization, and production localization from Slack or MS Teams
