If you’re a developer or localization professional, then you know how the other side can occasionally be the old
that delays you from doing what you really want to be doing.
Remember: it’s a two-way street. Developers often consider localization to be distracting and something that should be common sense. Consequently, there isn't really a huge sense of urgency or thrill around the idea. On the other hand, localization professionals constantly need to evangelize localization while depending on developers in order to see their work come to fruition. As a result of these mixed feelings, localization workloads swing from lows of waiting around for new builds to be created to highs of rushing like mad to lock in any LQA changes before the release at the end of the development cycle. Even some of the most mature localization teams integrated within R&D still face some of these reoccurring signs of an unfair relationship.
Previously, separating localization efforts from development has resulted in serious (read: expensive) outcomes. If localization is completely detached, products are built without being properly internationalized for scaling. However, with new technology,
, rather than being forced to work within each other’s space resulting apathetic attempts at communication or worse, residual feelings of resent.
Irreconcilable differences - Conflicting values
There have been leaps and bounds in development methodology and new, impressive localization management tools streamline a once very clunky path. Nevertheless,
development and localization still have innately different timelines and procedures from one another. While localization should be considered before development commences, the real bulk of its work occurs after development. Being tied to development, localization teams try hard to remain as agile as possible; however, the requirements of agile development processes tend to conflict with the overall idea of localization. There's a topic for another blog.
Infidelity - Problems with the status quo
Localization is a costly, time-consuming process that often employs external help in the form of LSPs, or
Language Service Providers. Furthermore, third-party LSPs, having very little contact with developers, rely on written style guides and strict hand-off procedures to adapt to the development process. Localization teams end up working more with external LSPs and less with developers within their own company.
Developers sometimes prefer working with other teams than localization as well, such as user experience or design. When a localization manager stops by a developer’s workspace, it's typically to report an internationalization bug or complain about his or her concatenated strings. Then the developer has to put on hold whichever cool project he or she is working on, rewind to the old project where the internationalization bug resides and squash it.
No more spark - Lacks progressive innovation
Being stuck in this nocuous duet has also caused a certain degree of stagnation, and the relationship has lost its flame. Besides changing from a linear to slightly overlapping model, not much has changed from the localization workflow of twenty years ago in regards to its relationship with development. Localization still lags behind its counterpart and then interrupts developers for help later on despite an otherwise lightweight agile development cycle.
New localization technology tends to focus on improving project management and increasing internal communication. However, the vastly superior issue -
the relationship between localizers and developers - has been almost entirely overlooked.
The inevitable - Time for a divorce
There was once a point in time when bad marriages always stayed together because there
was no alternative. Similarly, because of development and localization’s intertwined nature, they needed to stay together no matter what and just endure one another to achieve some degree of quality in a localized product.
But times have changed.
Products that regularly connect to a server for new content (such as with mobile apps or regularly updated software) can utilize cloud-based localization tools. With cloud-based technology, localized content can be stored and maintained apart from the development cycle. When a user sends a request to view localized content, that content is pulled directly from the cloud. Apart from internationalization and formatting issues that must be touched by developers, localized content can be created, tested, edited and maintained on its own schedule without the need for direct developer involvement. Thus, liberated developers no longer need to freeze their current projects to update localized content from a previous version or create new builds for testing.
Shared responsibilities - Taking care of the kids
But that’s not to say that development and localization can’t and shouldn’t remain friends. All things considered, they still need to work together especially when localization needs to be of utmost consideration as early on as (if not earlier than) development itself. One such example occurs when
simshipping, or simultaneously releasing a product in multiple languages.
What’s changed is that now localization can work alongside development and complement one another while not interfering with each other’s workflow or processes. Localization managers can create and test localized content directly without calling upon the help of a developer to create test builds. Additionally,
localization processes are not tied to the development release cycle. While it's true that new localized version should be released with a new feature, typos, terminology updates and other edits can be deployed immediately, bypassing any developer eyes and app store updates.
Rethinking the conventional position of localization within a development cycle can empower both developers and localizers to focus on their work in a mutual symbiotic relationship. Localization and development teams should be able to pass and greet each other in the office, smile and reflect on their past together, while at the same time, understand that the happiest and best solution for one another is to work individually, but remaining in sync with one another.
