A CMS for Video Games? We saw a need and filled it

I’ve spent some time reflecting on my decades in this industry. I’ve been around long enough to remember when game development was in its youth. There was an electric, shoot from the hip vibe in an exciting and burgeoning industry that in many ways has not changed. But early on, its global potential was not considered. Localization was an afterthought and the development of localized titles for our worldwide customers was a passing necessity, given to junior production personnel and completed weeks or months after release.  In the early 1990s, U.S. developers focused on the technology and storytelling of this flourishing industry. Relationships between both localization producers and translation houses, with the production team, were strained. Questions swirling around development teams included; “why do we need to think about different font character support?”, “who cares about accommodating the UI for growth?”, or even, “what is it about considering other cultures that might compromise our storyline?”

By the late 1990s, and with some corporate encouragement, more project leads began to incorporate a semblance of simultaneous development into their production cycle. Because we were all inexperienced, this meant, somehow, gathering data, sending it to a localization house for translation (in some far off land) and then incorporating that data back into the build structure for release. Processes and people were completely disconnected. As one of those lowly production personnel relegated to managing locs, trying to coordinate the changes that are inherent in production between all those distant parties was a nightmare!  Many a night I was copying and pasting data at 2am in the morning, trying to remember which file on my desktop was the latest.  There had to be a better way and we were a smart, innovative group; why were we doing it this way?

The crux came when I managed a project where all text data was compiled in a Dynamic Link Library (DLL) where few translation houses had the technical knowledge to handle, but it was my job to figure it out. There had to be some tool somewhere that could help manage the process, but nothing was commercially available. Necessity is the mother of invention, so XLOC, the first commercial Content Management System (CMS) for video games was born, as a means to keeping my own sanity and my job! If this tool was to be beneficial and not just a one-off for my own use, there was criteria we felt imperative to incorporate:

If simultaneous development was to be standard practice going forward, we had to find a way to integrate the localization process into the main language development, but with little impact to the hard-working production teams.  Our idea was to streamline tasks and make localizations in-step with main language development, rather than an afterthought.  This has still required evangelizing through the years, but I’ve seen growth and acceptance, as well as appreciation from all sides.

The bane of development is the recreation of something that already exists. In the early days of game development, it was done a lot and usually meant precious time and technical energy was wasted on creating something very specific. When we set out to create a CMS tool, we sought to fill a void and not recreate processes and applications that already existed. For instance, Translation Memory (TM) software existed so we did not need to corner that market. What we needed was a way to bring everyone together and connect development and TM management.

The realization that we were all global team members on the same product, working to make the game the best it could be for the wider global market meant that we needed to be connected. This was before the days of Google Docs, or even Dropbox. Creating a function that allowed all the valued players in the localization process, including production, development, translators, QA and even executives, have access to the communication, share and update data, was imperative. A trusted and centralized repository that could share string and project history, status, and process proved valuable to all partners and became the core of XLOC’s mission.

Working at a publisher house who had many internal and external developers with their own production practices meant that we understood that a tool had to have an open architecture to support the individualized goals for each development environment. Not only did this mean having the capability to support virtually ANY file format, but also to be able to cater to production management practices that varied between studios. The architecture of our creation had to be open, supportive of any file format and to allow for a customization process that these developers would find helpful.  Our motto continues to be “we don’t tell developers how to develop, nor translators how to translate”. We believe both parties are specialists in what they do and our task is to understand both and connect them seamlessly.

Production is a 24-hour cycle, particularly if using in-country translators, and tends to be more relevant and provide a richer localization experience. This means that data needs to be accessible to all partners at all times. XLOC became a web-based tool that allowed logins for verified users, accessing the latest data and running updates on their parts, keeping the localization process in-step with main-sku development.

As much as people want function, they also want automation. We had to incorporate API functionality to truly integrate with the developer’s process, and we have continued to grow our functionality as interact with developers and witness the processes that are used extensively.  However, we do request that our users understand the functions of XLOC manually before completely diving in for full automation. Production is far from an exact science and we want people to understand how to troubleshoot using the full extent of the XLOC features.

Our biggest competitors are teams that create their own internal tools and we totally get it. Internal teams know exactly what they need, what information is relevant, how to incorporate into the build process and who should access it. Adopting an external process has risks in this scenario because it might not have the exact specifications a development team deems relevant. In some ways, I agree, and that works for one project, and maybe a sequel. The risk lies in the support. Production is a system of change and change is constant. Unless a team is available to continue to support these internal tools, they end up becoming stagnant. We have talked to many people throughout the years who effectively recreated the wheel only to come to us because their teams were dismantled and their tool was no longer supported. Smaller teams, too, face limited resources in tool creation and support. We provide both support for our clients and development for continued features. As fragmented as development seems, and with thousands of developers worldwide, we are in a prime position to see trends and features that can benefit the greater whole of the localization process. Working with hundreds of clients for decades allows greater visibility into growth and potential for our global industry.

Localization has come a long way! Nowadays, the global market accounts for 30-50% of a games’ revenue. Simultaneous development is a given, with important factors being which territories to include for sim-release. Publishing executives continue to acknowledge the significance of our global market and there is a huge subset industry to manage the entire process. XLOC and others have been privileged to speak to the future generations of game developers at university level, educating them on the exciting advances, as well as stressing the global importance of this worldwide industry. It’s a great day knowing that localization is no longer relegated to the lowly production personnel as a forgotten task, yet we still have much work and evangelizing to do across the globe!