Software solution enables agile localization
Lingoport Resource Manager version 1.0, which was released early in November, is a software solution that monitors the software build environment for localization-relevant changes, flags and extracts changed resource files on behalf of localization project managers, automates the testing of both outbound and inbound localized resource files, and automatically replaces build-ready files back into the build environment in the proper location.
Over and above the automation it provides, Lingoport Resource Manager displays file status in a dashboard portal. By doing so, it provides a “window” through which all stakeholders can clearly visualize project status. This information can be leveraged to make plans, manage by exception, catch and rectify systematic errors, and set external expectations. Subjective judgment about project efficiency can be replaced by objective data reporting, and the risks of human error in file management are mitigated.
Lingoport developed the Resource Manager in response to requests by key customers that make use of their Globalyzer product. Globalyzer has been around for a number of years now, and is used primarily by large-scale publishers of global-enabled software products. Whereas Globalyzer’s main purpose is to parse through source code and expose internationalization errors, Lingoport Resource Manager is much more about pragmatically bridging the gap between development and localization. Nowhere is this more relevant than in companies that have adopted agile development as their core methodology.
Previous problems
Typically, one of the most difficult decisions that a software localization project manager has to make is when to begin the translation process. This is because the terminological heart of any software product is the graphical user interface (GUI). The GUI consists of what users see on their screens and, therefore, is the primary attribute of the product with which users interact. The GUI’s layout, behavior and verbiage communicates to users what the product is all about: what it does, what the user should do and expect, where the user enters and retrieves data. Once the GUI is completed, other product components such as online help, documentation, marketing material and other peripheral content can be imbued with consistent terminology.
The GUI itself is defined in a set of files that are dubbed resource files or resources. When code is properly written, every GUI element, be it a string of text characters, a data entry field, a dialog or window or a dropdown list of choices, is separated from code segment and placed in a resource file of some kind. The exact nature of a resource file depends upon the programming language in which the application is written. When the GUI is finished, it can be said that these resource files are no longer subject to change, so they, or a product GUI built from them, can be sent as a baseline reference to dependent processes such as technical documentation or localization.
That’s the theory, anyway. A look behind the scenes at the reality of software development reveals that the GUI is one of the most fluid parts of the entire project, often not being “frozen” — that is, left in a state that no longer changes — until very late in the overall development life cycle. This creates problems for the creation of product components that, by their very nature, exist to describe the operation and content of the GUI. Such components are, of necessity, created in downstream, dependent processes. In the classic waterfall development methodology, the development process supports prioritization of the GUI design and completion, even when the underlying business logic layer remains incomplete. Development teams that adopt a disciplined waterfall approach theoretically ensure that changes to the GUI are minimal after the “freeze” threshold had been passed. This allows downstream processes such as creation of technical documentation and especially localization to begin with the actors being given a reasonable degree of confidence that the remaining changes would not provoke unduly extensive rework headaches and cost. The localization manager thus needs to monitor the development process and judge when the GUI is sufficiently frozen, or that the rate of change has slowed sufficiently, to justify initiating the localization process. If this starts too early, the downstream processes will be doomed to inefficiency due to coping with change; if it starts too late, the delivery to market may miss an important deadline such as a trade fair or fiscal year end.
Localization is typically performed in a sequence that is reminiscent of the waterfall method. There are certain steps in the process that require completion before subsequent steps can be sensibly performed. For example, a sentence from a GUI error message needs to be translated before it is edited for grammatical correctness; the notion of editing a translation before it is translated is inefficient if not totally nonsensical. Likewise, there are a number of process steps that should logically precede others to optimize efficiency for the overall localization task.
Testing a resource file from the source language for localization readiness is one such step (Figure 1). Sometimes developers inadvertently introduce errors in resource files. For example, a developer might place a string identifier in the resource code and then neglect to assign a string to it. Assuming that the file in question then goes to localization without testing, and then subsequently comes back with a missing string, someone has to research whether the translator made a mistake or if the source string was previously missing in the file and therefore the translator had nothing to work with. The same can be said of other typical errors that occur in resource files, and the time spent tracking and rectifying such errors becomes inflated in proportion to the number of target languages. For that reason, the greatest efficiency can be achieved by testing resource files as they leave the build environment on their way to localization, and then again when they have come back from localization to ensure that file integrity has not been negatively influenced by translation. A set of tests that proactively exposes typical errors thus contributes greatly to reducing friction within the localization process.
Outbound resource files that are deemed localization-ready are packaged in a localization kit that is then sent to language service providers for translation. Reintegration of the localized resource files must be done with considerable care. Frequently, the source language resource files will have been altered by developers during the time in which their localized equivalents were out for translation. For this reason, the reintegration process must include an equivalency comparison among the build-readiness checks.
Until the early 2000s, the waterfall process dominated software development. Then came agile, a less strict development methodology that emphasized planning and execution cycles that covered much smaller chunks of product development delivered in shorter timespans. This approach promotes an iterative, evolutionary method of achieving the product that customers envision.
Rethinking the localization process to adapt to the iterative, ever-changing, and partially completed nature of agile development has resulted in a number of new tactics employed by localization project managers; however, to keep up with the rate of change, one of the principal tenants of the agile philosophy had to be turned on its head. In order to deal with the constant changing of content, processes and tools took on even greater importance than they previously had been granted.
In the context of technical writing, chunk-based authoring performed on XML-based platforms has aided authors to better match the agile software development cycle. Technical authors, of course, generally only write in one language. When chunks go out for localization, translation memory and terminology management systems capture the translations so that when a new version overrides the previous one, translated content can be reused. This, however, does not address the issue of coping with GUI changes that are captured in resource files. For that, a different type of tool is required.
First and foremost, changes in resource files must be detected on a timely basis; depending on the input from programmers as to when something relevant to localization has changed is insufficient. Programmers frequently underestimate the disruptive effects that changes to software GUI can invoke in downstream processes, or they may simply be focused elsewhere and forget to mention that changes have occurred. At the same time, stakeholders in downstream processes may not have access to the build environment in order to fend for themselves in such monitoring activities. And why should they? It is not their core expertise. For this reason, an automated solution that proactively monitors the build environment and raises flags when changes to resource files have occurred is a vital component to efficient localization.
Files in which changes have occurred need to be tested for localization-readiness. Running such files through an automated testing process saves an enormous amount of human effort and time, especially when the specific changes are automatically pinpointed prior to the files being packaged and sent for translation.
To keep the agile process rolling along smoothly, files returned from localization should also be automatically tested and placed into predetermined locations in the build environment. Having this done by a preconfigured, automated system reduces risk of human error, which could, for example, break the build integrity by depositing the returned file in the wrong place. And, as an added benefit, if errors are spotted in the test phase, defective files can be kept out of the build until they are fixed. These and similar issues are what Lingoport Resource Manager attempts to address. The Lingoport Resource Manager’s price point is quite a bit lower than that of Lingoport’s flagship product, Globalyzer. The Resource Manager is positioned in a price range that smaller development shops or single localization departments can more readily afford. This is not to say that the Resource Manager delivers less value — just that the value proposition is very different. Globalyzer drills deeply into source code to ferret out internationalization bugs that will affect core product functionality, whether localized or not, and its users are primarily software engineers. The Resource Manager concerns itself with files that comprise the presentation layer of the localized product. It will be used every day, hands-on, by localization project managers in conjunction with development team managers and more senior stakeholders to monitor and speed turnaround in localizable software resource files.
The Lingoport Resource Manager Dashboard
Although a lot of “mechanics” are going on under the hood, the most visible feature of Lingoport Resource Manager is the Dashboard (Figure 2). The Dashboard is a browser-based application that provides a central viewing portal for all the data that the Resource Manager gathers and collates. As such, it makes the information it contains available to anyone who has access to the web server on which it is running. Users might include development team managers, localization project managers, senior technical management and so on. This promotes greater transparency in change and fault monitoring, localization project management, file location and status.
The Dashboard is not new; it was previously a module of Globalyzer. But it has been expanded to include localization-relevant data generated by the Resource Manager. Underlying the data displayed in the dashboard is a set of configurable rules. Lingoport Resource Manager (as does its bigger sibling, Globalyzer) uses these rules as a baseline definition against which code is evaluated. The rules may be amended or modified, turned on or turned off, as needs dictate.The Dashboard also allows extensive drill-down capability within the various sections (Figure 3) so that users can track specific issues back to their root causes and to the timeframes in which they were exposed. Clicking on certain list elements, for example, will display more information about the rule violation, in some cases right down to the offending line of code. This will help development managers and localization project managers to understand what kind of problems are occurring, and where they occur, so that outstanding issues can be rectified and proactive intervention can be initiated for those issue types that are recurring. Source violations will usually have to be taken care of by development team leads, whereas translation violations would fall within the province of localization managers to resolve, either by their own team or by bouncing files back to translation suppliers.
Installation and operation
The accessible layout and informative richness of the Dashboard belies the complexity of technical processes going on under the hood. Installation of Lingoport Resource Manager is not a single action like installing a translation memory tool; some technical expertise is required for the initial deployment because the application touches and interacts with a lot of modules in the development environment, not to mention serving up web pages for the Dashboard. After this is done (and it is a one-time affair), individual project configuration is defined in a relatively uncomplicated and well-commented XML file format that does not require very much XML knowledge to understand (Figure 4). Interaction with the product, however, is carried out by entering commands with parameters in a DOS-like console environment. In this regard, the level of expertise required can be likened more to that needed for writing programs in SAX Basic for SDL Passolo or similarly conceived scripts for Alchemy CATALYST, although the range of potential commands to master is not extensive.
So why not just go with a visual localization tool? After all, the better versions of these tools have some types of built-in evaluations of file integrity. There are a couple of reasons. For one, Lingoport Resource Manager is translation tool-agnostic in the sense that it creates copies of resource files and places them in a discrete location outside of the development environment where they can be retrieved by localization project management resources, but it does not impose a tool selection for the actual translation. A localization department may have a mix of vendors, some of whom use Passolo, some who use CATALYST and, perhaps, some who use other tools. For this reason, it would be advantageous to have the “raw” resource files, albeit files that have been tested for localization-readiness, but which have not been loaded into a tool environment to be prepared for dissemination to the translation supplier. This advantage is augmented on the return trip, whereby the translated files are automatically replaced in the correct location by the Resource Manager. Lingoport has left the actual check-in of resource files to the version control system as a non-automated task. There are simply too many systems to support and no industry-standard check-in protocols.
Another powerful advantage of Lingoport Resource Manager is the automatic web-based reporting. Users do not have to have a license to view overall project and file status; nor do users have to employ their licensed visual localization tool to create or export reports. All stakeholders have to do is view the web page and click through to specific data points as desired. Typical stakeholders would be members of the development team, the team manager, the build manager, the quality assurance manager, the product manager for global markets, the vice president of engineering who needs to oversee multiple projects, the localization manager and project managers, or even external vendors who need to monitor how well the deliverables are faring once reintegrated into the build environment.
Although the configuration paradigm for the 1.0 release is challenging for the coding neophyte, any developers or build engineers worth their salt would have no problem with it. Compensating the lack of user-friendliness for non-coders is Lingoport Resource Manager’s portability to the Linux and MacOS operating systems. This gives it greater breadth than some resource management solutions. Also, Lingoport is currently evaluating whether or not to add a Windows-based configuration user interface to a future version. Because the Resource Manager was developed in response to Lingoport customer input, what this enhancement might be or what it might look like will presumably depend on early adopter feedback. But for now, users will have to not be intimidated by having to initiate operations through entering commands like the example shown in Figure 5.
Lingoport has wisely not tried to create an ungainly, all-encompassing application right out of the gate, and therefore has restricted the supported file formats to several most commonly encountered at client sites during their internationalization consulting activities. The inaugural version 1.0 supports properties files (Java type resources), RESX files (.Net), PO files (PHP), .rjs (custom JavaScript), RXML (custom XML), RC (Windows C++, Delphi), and MSG (GNU C/C++ applications). Support for additional file types will be added over time, based on customer demand.
Lingoport Resource Manager provides a much-needed and useful communicative bridge between development and localization, typically two corporate entities that suffer from a mildly uneasy relationship, especially within the context of agile programming environments. By exposing vital project data in a web-based format that can be viewed in real time by all stakeholders, the Resource Manager currently enjoys a niche not covered by more traditional localization or translation tools. Although under-the-hood operation is not trivial in the sense of interacting with an intuitive user interface to initialize project data delivery, it can be automated by localization-savvy configuration management developers or programming-savvy localization engineering specialists to produce regular updates in a highly accessible form that delivers all the information that most stakeholders require.
Lingoport Resource Manager was de-?veloped through garnering input from customers to whom Lingoport provided internationalization consulting services, and thus directly addresses real-world problems regularly confronted by a variety of experienced internationalization and localization specialists from both the client and the provider sides. The solution should be of particular interest to organizations that already have adopted agile development methods or are considering doing so.
