 |
|||||||
 |
Welcome to the Rubric Newsletter.In This Issue: PM TIPS: Tips, tricks, and strategy from Rubric localization project managers. Welcome once again to the Rubric newsletter, where we bring Rubric's Better Localization Experience to your in-box. Past editions of the Rubric Newsletter can be found on our Web site. We encourage you to forward this newsletter to anyone interested in localization topics. If you are receiving this newsletter from a friend, feel free to subscribe to our newsletter; you will receive your copy as soon as it is published. Share Your Voice Want to contribute to the Rubric Localization Newsletter? We are actively seeking topics for either the business or technical articles, and for a new section on L10N Tips, where you share your tips and tricks for improving your localization projects. Send an email message to our editor with a proposed topic or tip and we will guide you through the rest of the process. |
|
|
||||
|
PM TIPSRubric localization project managers know the ropes, and are happy to share their top localization tips with you in every newsletter, and on the web at www.Rubric.com/pmtips.Early UI disclosure: "Easy access to the English UI software (and also any existing localized versions) should be provided to your localization vendor at the start of the project. If UI is to be translated, linguists will use the software as contextual reference. This will limit the number of questions raised, that you would have to find time to answer. Overall quality of the translations can be improved by providing early access to the UI software." — Jo Clayton, Lead Project Manager |
| |||||
|
RUBRIC NEWSSilicon Valley Localization Pro Meeting — October 3rd: Rubric is inviting Silicon Valley localization professionals to meet for the fall Birds of a Feather event in Santa Clara. Past events have drawn localization pros from Adobe, Verisign, VMWare, ViewCentral, EFI and other valley powerhouses. Photos from our last BOF event are online! This time around, Senior Project Manager Susannah Eccles will present on "Reducing the costs of localization through effective internal planning and preparation." Everyone likes to contain costs, and Susannah has a number of tactics you can use to keep your projects under budget. In addition attendees will partake in some good food, great conversation, and meaningful exchanges of ideas with their peers in the technology localization world. If you would like to be considered for an invitation to this limited-seating event, please email us for an invitation and give us your name, company, and email address. L10N Forum is now online: Rubric is sponsoring the L10N Forum (www.l10n-forum.org), a community for localization professionals. This no-advertising forum is a place for you to find and commune with other localization pros, to share tips, tactics, war stories and job postings. Though a L10N is a new forum, there are already threads on language dialects, encoding issues, web/SaaS localization, DITA and more. Drop by the L10N Forum today and join the discussion. Rubric brings Adobe CS3 to global markets: Adobe's Creative Suite 3 (CS3) was released to markets around the world to great acclaim. Rubric is proud to have played a role in the localization of CS3. Rubric established unique business and project models to handle any customer need. With CS3, there are over 10,000 pages of documentation geared to people who may or may not be technically astute. The challenge in localizing such a massive product for such a diverse audience lies in maintaining quality throughout. If you are involved with digital content creation, you owe it to yourself to evaluate CS3. |
|
|
||||
|
COMING TRENDS AND DISASTERSby Ian Henderson, CEO, Rubric |
|
|||||
|
Rubric has seen the craziness first hand. The Internet has changed our business, and we see the changes in our software vending customers. Between new markets and business models, how a company launches a product or outmaneuvers competitors is now a much more complex issue, one where localization makes a difference by entering the product lifecycle earlier. I'll discuss some of these issues in a moment, but I want your input as well. At the Rubric-sponsored L10N Forum, there are a set of polling questions to help measure in which direction the software industry may be heading and how these changes impact product decisions. I encourage you to visit the L10N Forum and take these single-question polls today http://l10n-forum.org/viewtopic.php?t=84 http://l10n-forum.org/viewtopic.php?t=85 http://l10n-forum.org/viewtopic.php?t=86 http://l10n-forum.org/viewtopic.php?t=87 Software architecture and planning The Internet has changed everything in the software business. The entire value chain — from development to support — has been permanently altered by inexpensive global access. This is especially true in the SaaS business model, and the potential for selling services to a global market on the first day of delivery. From engineering, maintenance and customer support perspectives, creating a SaaS product is architecturally different. Aside from being Web-based, the need for a multi-tenant structure that serves multiple languages and cultures simultaneously creates interesting design and architecture tradeoffs. Clearly a single architecture that works in all regions is the best from a maintenance standpoint; but it is more time- and resource-consuming to create, and trickier to localize effectively. The first of the L10N Forum questions tries to get the pulse of the market from the localization professional's perspective. Are you delivering a SaaS product currently? Are you planning on vending one in the next two years? If you answered yes to either of the first two questions, the follow-on query asks if you created a localization plan that was incorporated into the product design. (BTW, the ongoing results of these polls are available immediately at the L10N Forum, so you'll know the trends as soon as everyone else). SaaS has some peculiar problems in regard to localization. Part of the value of SaaS is that the product itself is always being fixed and improved — with no lag inherent in the update process. This means the base product — typically presented in English — is a moving target. Finding a quiescent point at which to localize a product is nearly impossible. Thus the localization partner has to be adaptive to the work flow of the SaaS vendor and be able to manage process and teams in more fluid ways. SaaS localization problems often surface in testing. It can take several weeks to localize a SaaS product. If a bug is discovered in the localized version, and the bug was originally in the English implementation, quite often that part of the product has since been changed. Locking in or archiving the base implementation is critical in back-tracking bugs, fixes, and moving the localized product forward. SaaS customers and Web 2.0 users can exacerbate the situation as they often have the ability to customize the user interface. Occasionally a minor change instigated by an administrative user can ripple through a SaaS product, affecting all downstream users. This is reflected as being a "poor translation," when in fact the original work was sound. Unnecessary helpdesk calls begin coming in, ones that are difficult for the helpdesk to resolve since the UI no longer looks like the original product. SaaS providers need to be picky about which parts of the UI they allow customers to modify, especially in localized content. Resolving localized UI issues is tricky, given limited language skills of the helpdesk staff and their lack of insight into the localization process. A lot of money is being wasted in the SaaS world with these preventable problems. New markets New markets are opening up around the world, and these new markets — often devoid of traditional software infrastructures and preferences — are ripe for exploiting. When countries like China, Latvia and Azerbaijan have significantly higher GDP growth rates than Germany, France and the United States, software vendors' globalization decisions must be reviewed, and which regions to target may get shuffled. When international software markets were focused on eight heavily industrialized countries, localization decisions were fairly simple. Today the cumulative market within smaller industrialized countries and larger developing nations make them targets that should not be automatically ignored. The other poll questions at the L10N Forum ask what your next new target market is, and what are your expected top-growing revenue markets for the next two years. As localization professionals, you have your thumb on this pulse and can share these insights anonymously. A newish acronym is becoming an industry norm — BRIC, which stands for Brazil, Russia, India and China, the new high-growth technology consumers. Localization for these previously underserved markets is coming to the forefront. Recently Sun CEO Jonathan Schwartz confided that the decision of Open Source Java was finally made because the Brazilian government flatly refused to adopt any technology that was not open. The economic power of Brazil, China, India and Russia is such that your localization priorities may soon change... if they haven't already. IDC estimates that IT spending within these countries is growing by double digits, with Brazil hovering near 13% growth, China with 16%, and 19% in Russia. India IT spend is rocketing at 21% annually. Summing it up Rubric software customers — those not tied to specific hardware, at least — have shown a strong migration pattern to SaaS, with recurring questions about how to localize effectively. The topic is broad and may well come up in a future Birds of a Feather meeting in Silicon Valley or Boston. I will let you know. |
|
|||||
|
SOFTWARE GLOBALIZATION: WHAT COMES FIRST?Adam Asnes, CEO, Lingoport |
|
|||||
|
When it comes to software, at some point those business drivers are going to have a very important consequence for the software company's development efforts. Whether that's handled gracefully or not has a lot to do with how much that development team understands the requirements involved in adapting their software to support multiple locales, and the resources and time necessary to execute. That effort — of adapting products so they can support multiple locale requirements, including languages and all kinds of formatting and data management — is what software internationalization is all about. It involves re-architecting and rebuilding a product for a whole new set of locale-dependent user requirements. If this is done right, your product can be efficiently localized for any market in the world, while working elegantly with your customers' worldwide data. Then there's one product to support and maintain, which works everywhere, and affords efficient localization on an ongoing basis. The catch is that making products world-ready is typically expensive, and takes a long time — longer than everyone thinks it will. Delays pile up from months to even years. Time to market can get even more expensive in terms of delayed or lost revenue and diversion of resources from other efforts. Before you localize software, make certain you understand that the internationalization effort is well planned and executed. Internationalization planning often starts with shortsightedly focusing on the translation of a product's interface. Strings, or user-facing words and messages, must be separated from the source code into either resource files or a database, in such a way that they can be dynamically identified and replaced with translations. This is a long and tedious process, often done by trial and error. It can be very challenging to identify and externalize all the strings buried within large amounts of source code, but it doesn't have to be that way. And translating strings is the easy part of the process. There's more to software than the user-interface presentation. Most software and sites interact with users — taking, storing and transforming their data in some manner. Software has to be reengineered to manage data input in multiple languages, and must deal with all kinds of variables: extended characters involved with worldwide written scripts, changes in numerical formats, address formats, telephone numbers, sorting, dates and more. The database needs schema changes that ripple throughout the product. Character encoding and glyphs can further affect the database setup, as well as functions and pages throughout the application. Then there's optimizing and implementing the framework of how locale selection and software behavior will occur throughout the application. When you figure how much software engineering was needed to create a product in the first place, you can begin to understand how internationalizing a product can be a very serious and involved effort, as the source code must be pulled apart and rebuilt with new requirements. Lingoport focuses entirely on solving that internationalization development risk and objective. Globlayzer is our product tool for supporting entire engineering teams in their internationalization engineering efforts. Since we do so much internationalization engineering ourselves, we are probably our own product's most active customer. Globalyzer first helps us scan large code bases, so that we can accurately find, count and estimate costs for fixing internationalization issues. During a development effort Globalyzer helps us scale many of the refactoring efforts across our teams in concert with our customer's developers. Globalyzer provides a system for checking future development efforts so that products remain internationalized throughout their lifecycle. When you know all the issues and have productivity tools to fix them, you can more accurately integrate localization processes, especially when bringing your language service provider into the workflow. This means you manage a more predictable development effort and achieve a faster time to market, with a finished, elegant product that performs gracefully for any worldwide customer. |
|
|||||
|
|
|
|||||
