Internationalization Software Globalyzer 3.6 Release

The latest Globalyzer Release Features new Programming Languages, new Rule Sets, Additional Support to Help Software Development Teams Share the String Externalization Work, and an Internationalization Scorecard

Lingoport, a provider of i18n tools and internationalization consulting services, announced yesterday the release of Globalyzer 3.6. Lingoport also announced that it will participate in an online panel presentation along with Zynga, IBM, and Hewlett-Packard, to discuss software development and localization on Wednesday, August 3rd.

Globalyzer—a client/server software internationalization system—assists development teams in internationalizing source code as an integral part of future releases. Globalyzer finds, fixes, and monitors issues quickly so that software applications are ready for localization and worldwide customer requirements.

The latest Globalyzer release features many new enhancements, including new supported programming languages: Qt and ActionScript plus enhanced XML and MXML support. Globalyzer 3.6 also adds shared string externalization support to help development teams working together on internationalization efforts as well as an internationalization scorecard, enabling managers to track key internationalization metrics over time.

Adam Asnes, founder and CEO of Lingoport, notes: “We are very excited to announce that Globalyzer is further extending support for programming languages like ActionScript, used in Flex and Flash applications, and enterprise global readiness analysis that we’ve seen become more important among our customers. We also keep adding features to help teams of developers support internationalization, as that’s an endeavor that runs across teams rather than just individual developers.” He continues: “More than ever, Globalyzer assures that a software application is global-ready as part of the development cycle, thus enabling companies to enter new markets faster while raising quality and lowering worldwide development, translation, and support costs.”

Lingoport’s software i18n tool now also features an internationalization scorecard. The scorecard system provides a dashboard of internationalization status and progress using XML data collected via scan history using Globalyzer’s Command Line. The i18n scorecard was recently discussed in an hour-long webinar presentation and featured guest-speakers Mike McKenna, Sr. Manager, International Engineering, from Zynga, and Leandro Reis, Senior Globalization Program Manager, from Adobe Systems. A recording of the presentation may be viewed at: http://www.lingoport.com/internationalization-webinar-video/#17

The Globalyzer 3.6 release notes are available on Lingoport’s website at:http://www.lingoport.com/software-internationalization-products/globalyzer-3/release-notes/

Top Ten Internationalization Mistakes to Avoid

This is a summary of an article written by Adam Asnes of Lingoport. For the full article, visit http://www.lingoport.com/internationalization-management-mistakes 

Sometimes the best way to learn is through mistakes you have made in the past. While this may be true in the personal arena, making mistakes in business is costly. Lingoport has seen a number of internationalization mistakes cost companies money in the past. Here’s a list of the top ten problems businesses looking at internationalization need to realize.

  1. Don’t forget what drives internationalization: new customers in new markets
  2. Don’t assume internationalization is just an older software legacy issue: no framework, however new, is capable of internationalizing itself.
  3. Don’t assume you can treat internationalization like any other feature improvement when it comes to source control management.
  4. Don’t assume internationalization is just a string externalization exercise: the scope of i18n is much greater.
  5. Don’t wing it on locale: be sure to consider both language and location.
  6. Don’t create your very own internationalization framework: speak to somebody who has done it before.
  7. Don’t think that the team internationalizing your software can work without a working build: developers should be able to test as they go.
  8. Don’t run out of money: projects suffer from underscoping, resulting in costly release delays.
  9. Don’t use a half thought-out character encoding strategy: use Unicode.
  10. Don’t use your same testing plan, or just rely on localization testing, when your functional testing needs to grow to include internationalization requirements.

For full details, read the full article here: http://www.lingoport.com/internationalization-management-mistakes

Worldware: Software Static Analysis

This presentation from Adam Asnes and Olivier Libouban of Lingoport progresses from beginning an internationalization plan to actually implementing that effort. There’s a big difference in describing the process of externalizing Unicode strings and actually doing it through an executable plan. This four-part presentation will dive into using internationalization static analysis using Globalyzer while looking over the metrics for success in such a project.

Part 1: The business case for internationalization, character encoding, a Java internationalization example and an overview of Globalyzer’s static analysis.

You may also view this presentation on Slideshare:  http://www.slideshare.net/Lingoport/wordware-2011-lingoporti18nplanningstaticanalysis

Part 2: Requirements in i18n software engineering, locale and code architecture analysis:

Part 3: An example of how Globalyzer is used

Part 4: An internationalization project plan:

Unicode: the Movie

Programmers and developers recognize Unicode as a super set of characters from nearly every language in the world and as a necessary standard to oblige to.  Unicode represents a set of of over 109,000 characters. While that number is impressive, the visual representation of that many characters is simply astounding. I came across a video on YouTube that flashes one Unicode character per frame; it lasts over 30 minutes. Watch the video for about 30 seconds, and you’ll get the idea.

Also, Lingoport‘s Adam Asnes shares how Unicode came into being and how it is a valuable tool for developers to develop in other languages.

Worldware Presentation – Bringing I18n to MT Development: Challenges, Solutions, Case Studies

The affect of machine translation (MT) in the globalization industry has been astounding do to MT’s ability to cut costs and shorten the time to market for products. With growing demand for MT, the question is posed as to how MT applications are able to overcome new linguistic and technical challenges (such as internationalization) and how these problems are being addressed by companies using machine translation.

Presented by:

  • Olga Beregovaya, CEO of PROMT Americas, the Enterprise division of PROMT

Lingoport Webinar: Supporting Internationalization Across Your Enterprise With Globalyzer 3.4

Recording Available Below

There is tremendous value in knowing if a product is global-ready as part of your development cycle. Large amounts of development, marketing and branding dollars are at stake. Yet often, the only way software gets verified for localization, is during the localization process itself, or based on a limited series of manual interface testing. That’s way too late in the development cycle to be efficient and a very incomplete way to address the issue.

There are all kinds of products to support issues like software security and efficiency, but how about checking on internationalization, which for many companies is a hefty and vital product requirement for a good share of company revenue?

In this webinar, we’ll be demonstrating how Globalyzer 3.4 (our new release) finds, categorizes, tracks and helps fix internationalization bugs in source code using static analysis.

Webinar: “Supporting Internationalization Across Your Enterprise With Globalyzer 3.4”
Date: Tuesday, November 30th, 2010
Time:
11am – Noon PST
Where:
Your desktop
Watch at:
http://vimeo.com/17364680
Cost: ComplimentaryPresenters: Adam Asnes and Olivier Libouban of Lingoport

We’ll start with some source code and then:

  • Analyze it for internationalization issues
  • Customize “rule-sets” so that specific issues to that code can be address
  • Show how that information can be accessed and shared among development team members
  • Integrate automated Globalyzer static analysis via command line
  • Support testing initiatives

The Webinar targets technical managers, software engineers, test engineering managers, QA managers, internationalization and localization managers, and anyone facing ongoing software globalization and localization challenges.

Note: We’ll be diving straight into coding issues and will be skipping internationalization basics. If you’re looking for a presentation on internationalization and localization basics, please visit this archived presentation from Localization World: http://vimeo.com/16345751

About the presenters:
Adam Asnes founded Lingoport in 2001 after seeing firsthand that the niche for software globalization engineering products and services was underserved in the localization industry. As Lingoport’s President and CEO, he focuses on sales and marketing alliances while maintaining oversight of the company’s internationalization services engineering and Globalyzer product development.

Olivier Libouban, a native of France, has been working for 25 years in the software industry, for large corporations and start-ups, as a software engineer and as a project manager. Olivier has a wide ranging experience in the US, France, Switzerland, and Norway, in R&D departments as well as for client projects of all sizes with complex software environments.

The Need for Internationalization (i18n) in Administrative Solutions: A Case in Point with Region Centre

By Olivier Libouban, Software Project Manager at Lingoport.

A Region is an administrative layer in France, with elected officials, getting tax Euros, and setting up programs and initiatives for the EiffleTowercitizens. Part of the responsibility of any region is also to provide software solutions to the citizens. Part of the responsibility of any region is also to provide software solutions to the citizens, with significant budgets: the IT department of any Region manages bids, responses, and supervises the implementation of the solutions.

A case in point for “Region Centre”, situated close south west of Paris, is the need for an e-learning platform, dealing amongst other things with budgets, financial institutions, training institutions and citizens able to register and follow classes, either on-site or on-line. The request for proposal of such programs is sent by the IT department and gives the context, the functional needs, and the requirements at large for this type of program, including strategic technologies, such as Portal by a specific vendor. The entire platform may be composed of a large number of software components, in this case ranging from the software infrastructure pieces, such as Web application server, LDAP, and databases, to specific functional components, such as an e-learning tool to be integrated in the overall software and hardware platform.

The IT department oversees the responses to the request, and solutions which do not play in a French locale cannot be accepted. All components must behave and interact with each other, be it in terms of encoding, of searches, of collation, of UI presentation to citizens, training institutions, financing institutions, administrators of the system. In other words, the budgets for an administrative program are targeted at i18n compliant software.

Those administrative programs might be at a city level, a county level, a region level, a national level, even at a pan-national level, such as with the European Union, which serves citizens of Europe at large. The combined budgets of those IT departments are simply very large and can only be applied to i18n solutions.

Video Recording of LocalizationWorld Presentation: Intro to Internationalization and Localization

Internationalization and Localization experts Adam Asnes, of Lingoport, and Angelika Zerfaß, of zaac, recently presented at LocWorld in Seattle. Their session “Intro to Internationalization and Localization” was moderated by Daniel Goldschmidt, principal consultant and cofounder of RIGI Localization Solutions, and is now available for online viewing.

The one-hour recording of their presentation provides an overview over the different areas in internationalization and localization projects where best practices exist — starting from the concept of internationalization and how it is applied to project management dos and don’ts and the tools and technologies used in the field.

The business case why US companies need to internationalize their software in order to sell to the Canadian Government

In Adam Asnes’ article in the September 2010 issue of MultiLingual, he illustrated how business cases for US companies can drive their need to internationalize their software in order to sell to the Canadian Government, or to sell broadly in Quebec. I liked in his article how he mentioned that companies may adapt their software because of sales-driven reasons rather than part of a broad global marketing initiative, which have “different needs-drivers reflected in deadlines, resources and scope” than regular, consistent localization projects.

Adam goes on to describe very well, for both the techie and sales person alike (me for example), what needs to be completed to get the software localization-ready and how Lingoport rocks at helping companies with that process. Here at Milengo, we assist clients with their language support commonly after Lingoport has finished their work. And we too notice clients’ needs for Canadian Language support is different when it is deal-based, rather than as part of a broader sales plan, so I too will focus my ideas on that part. I wanted to use this blog to illustrate some examples of projects we’ve worked on to give readers ideas on what processes and technology are available and what is do-able, to help stretch your budget when sales lands a big new deal in Canada.

Let’s make the assumption that your company is doing very well and the software you produce is awesome. Sales are booming in North America. The Sales Director got a big contract with the Canadian Government. Big deal and big money. It’s signed after the champagne has been popped, you’re told that you have 3 months to deliver a Canadian French version, with documentation, since it’s required by law in Canada. And if it’s late, the company will have to pay a fine for every-day its late, eating into profits and good will. So after a big gulp of bubbly, the process begins.

Luckily, you know Lingoport already from Adam’s excellent articles in Multilingual. His company helps your developers in completing the i18n of the software so that it can be localized. He did it on-budget and before he promised, just because that’s how Lingoport rolls. Milestone 1 completed. Then you see you have about 10,000 strings for translation as well as help and user manuals, which require about 200,000 words for translation. Oy vey. The volume is too much for your staff in Canada to do it internally within this timeframe. What options can you consider?

Option 1: Have an LSP do the translation for you. Luckily, your sales team collaborated with you closely and the deal was priced to allow for high-quality human translations in Canada. You can create a glossary from the software translation, which forms a bed-rock for future updates. Consistency in your software, documentation and customer communication is recorded and used across all documents, lowering costs, increasing quality and enhancing the brand experience (a big topic that we’ll go into another time). Sounds good, right? With all those happy French-speaking Canadian customers, it may get you thinking that a more developed localization strategy might not be a bad idea after all?

Option 2: Your sales team did not collaborate with you, and the overall price of the package sold was too low. Your manager is balking at the double-digit figures for the cost of the documentation localization since the budget is not available and you have limited financial resources. Alternatively, perhaps its not a priority to have this done with high-quality human translations since this is a one-off deal. Options to consider include:

  • One of Milengo’s customers had some 1.5 million words of help-desk and customer support information that needed to be translated in a month a half in order to outsource call-center operations. Do-able? Yes! Did they have a budget of ~ $500,000? No. To get around this we worked with our partner AsiaOnline to develop a customized, enterprise-level statistical machine translation engine that uses sophisticated algorithms to provide machine translation results. To make the translations publish-ready, human linguists reviewed the machine translation output to correct errors, fix stylistic problems, etc so that it looked and felt correct. The overall saving was over 50%.
  • You want to leverage your in-house team of people in Canada, but need to make them more efficient. How about taking the glossary from your UI and use it as a basis within the Google Translator Toolkit? The Google engine will produce a translation for you using your glossary as a reference point, and afterwards, your in-house team can correct and fix the errors and improve style. Or you can have an LSP like Milengo do it for you. Depending on the nature of the content or corporate culture, if may not be appropriate, but it is an option that you can consider. Google is doing more and more of their own translations this way, and we’ve helped them with correcting the output of their translations using their own toolkit.

Option 3: You can do a mishmash of all 3 above. The UI is translated by your in-house staff (i.e “the humans”) since they are the experts. The documentation is translated by AsiaOnline’s customized statistical machine translation with human post-editing, and Google Translator Toolkit is used for internal communication in Canadian French <> English.

Option 4: While the above mentioned scenario is unlikely since you are internationalizing your software for the first time, if you did have a French translation, we could leverage that considerably. An adaptation from Continental French to Canadian can be done. While both languages are French, there are of course differences and copy-editors can go through and change terminology, style and make the local feel local, saving considerable time and budget.

There you have it. Of course each option, scenario and client requirement is more complicated and detailed than portrayed here, but hopefully it gets the juices flowing in terms of what can be done.

Post written by Adam Blau, Rebellion Leader at Milengo, a global language services provider.

The Business Why and How of Simship

This article was originally featured in the July/August 2010 issue of MultiLingual Computing Magazine, in Adam Asnes’ Business Side column. 

The subject of managing releases over worldwide markets can be a contentious one, with pros and cons on either side of business and development cases. The concept of simship is that if you are releasing your product to worldwide markets, you do it all at once rather than first releasing to your home market and then following with localized versions later. I can’t say that any one approach is right for all organizations, business situations and products, but I can share with you some of the organizational, procedural and business issues that contribute to successful simship global releases.

When a company commits to product releases that serve a worldwide customer base, there’s a long shadow cast on revenue, marketing, sales teams and of course development practices and testing. It’s a challenging logistical undertaking to release software products in multiple markets, requiring well-integrated planning and practices. It’s no wonder simship is viewed alternatively as difficult and impractical to the best thing a company can do. Let’s consider a few of the issues within any organization, starting with the business case.

Internationalization and localization are always in pursuit of a business case, and one exists both for and against simship. That said, the business cases tend to vary based on the global perspective and maturity of the company. The case for simship is strongest among experienced global companies. Their revenues are already global, so delaying releases for localized versions only serves to delay resulting new release revenues. There may be good reason for adding secondary tiers for some local release schedules, but products really should be internationalized, with a clear path for localization and testing within the development path. In practice this isn’t the reality, but there’s quite a bit of agreement and successful data on the business case existing for simship with this class of company.

When companies are relatively new to global markets, they generally tend to put less of an emphasis on simship with new releases, and more of an emphasis on market or business agreements as drivers for their efforts. Perhaps they have a new customer or distributor that must have a localized version. In that case, synchronizing new version development with localization is usually—but not always—an afterthought. This is because the company sees its prime revenues being driven by current product customers. New releases boost sales, renewals and competition, so that connection is strongest where the current customers are. We’d still argue that even under these circumstances, simship should not be pushed aside, as there are gains to be made both for revenues and operations.

Time and Revenue Projections

Attached to initial time to release and revenue opportunities are quarterly and annual growth numbers. If a product is expected to grow sales by percentages outlined and expected in a marketing plan over months, quarters and years, significant delays in turn make those projections difficult, if not impossible, to meet. Delays add up to real dollars. Now let’s leave the business case behind and look at software development organizations. It is extremely common among both development and localization teams to view localization as a tail-end process. But this is a critically limiting perception if your company is committing itself to serve global customers. Practically, a company shouldn’t build a product with a requirement as major as supporting multiple locales as a tail-end process. Even in cases where legacy code is now being first internationalized for global customers, once that adaptation is complete, from then on localization should be included as an expected part of the development process. That means including requirements for planning, architecture, development implementation, testing and release.

I asked my internationalization colleague Tex Texin to add some words about this. He seconded that as with many other aspects of globalizing applications, development organizations tend to see just the work and delay to releasing their product and not the benefits. And although we work to plan to minimize the pain, there is cost to achieving simship. However, exercising the localized versions often uncovers critical problems in the product core that can require urgent updates, recalls or even the creation of specialized tools to repair customer data in the field. In that context, simship is not only a requirement to be in the international markets and significantly enhance revenue, but is an important part of product testing preventing problems that are costly to repair and damaging to both reputation and future domestic sales.

Tactics

Simship nearly always seems to be the outcome of an internationalization implementation. So, we have some experience working with legacy code that we are internationalizing and then merging with concurrent new development, building localization proactively into the process.

We find and work with the localizable content embedded in the code first. We gain a clear estimate of localization costs by examining those strings, even while they are still embedded in the code using static source analysis. That’s important because it allows the budget and financing mechanisms of an organization more time to accurately fund the localization. Then we systematically provide externalized strings for localization as we go along in the project, rather than waiting until the end. We also perform static analysis on concurrent new feature development so that when we merge legacy and new code, we minimize the risk of expensive surprises. We build functional internationalization and localization test cases and execute both. The internationalization functional testing can be performed by testers regardless of linguistic proficiency. However, because we have been localizing all along, we are also quickly ready for linguistic testing. The combined processes are extremely effective in finding both functional and linguistic defects that may have passed through if performed as an afterthought.

Agile Development: It’s one thing to talk about including localization into your internationalization and development process on large-scale efforts, but what about smaller scale and rapid agile releases? Turns out it’s really no different. I talked to Mike McKenna, globalization manager at Yahoo!, to get some perspective. An extreme example is the release cycles for Flickr, Yahoo!’s photo sharing social network. Flickr sometimes rolls out four to six releases per day, holding the expectation that developers can get immediate access to translations they may need, likely to be small UI changes. Then they pride themselves with directly connecting their developers to users, without intermediaries, to fix issues that may arise from localization or functional changes.

Yahoo! has other software, such as its Open Strategy Platform or Yahoo! Application Platform, which typically have six-week release cycles. In this case, there is a UI freeze before the release sprint so that localization can be integrated into the final release sprint. Developers work with their localization managers and ensure any last-minute tweaks that may become necessary to the UI during the release sprint are well coordinated.

Security: Let’s go back using our timetunnel to the 1990s: Windows 95 was first released in August 1995, its first service pack was released in February 1996 and the second pack in 1998. The localized versions were always lagging behind: Microsoft first released the “Enabled“ version, which was not localized but could run software in your language. A few months later, Microsoft released the localized version. Today, Microsoft and other companies release security patches on a monthly basis if not on a weekly basis. Can you imagine releasing the patch in North America first and only a few months later in the rest of the world? Simship enables the release of security patches and other critical patches on a timely basis to all markets and prevents security glitches.

Internationalization as Enabler

The success of localization and the ability to coordinate simship processes are directly dependent upon the quality of a product’s internationalization as well as the development team’s ongoing internationalization practices. Internationalization is the software development enabler, and without it or without a consistent internationalization benchmark, localization and particularly simship get broken. As the saying goes, garbage in, garbage out. Simship takes a little more planning, time, tools and coordination, but it’s hardly an onerous process. Like a lot of things, your organization has to be aware of the benefits and just do it. Then the actual doing is clearly achievable.

About the Author

Adam Asnes is President and CEO at Lingoport and enjoys investigating how globalization technology affects businesses expanding their worldwide reach. Adam is a sought after speaker at industry events and a columnist on globalization technology as it affects businesses expanding their worldwide reach. He often writes articles for localization, internationalization and globalization industry publications and enjoys cycling and Colorado’s Rocky Mountains; he can be reached by clicking here.

Lingoport’s Internationalization (I18n) and Localization (L10n) Tools and Consulting Solutions

Founded in 2001, Lingoport provides extensive software localization and internationalization consulting services. Lingoport’s Globalyzer software, a market leading software internationalization tool, helps entire enterprises and development teams to effectively internationalize existing and newly developed source code and to prepare their applications for localization.

For more information on how Lingoport can assist you with all of your internationalization and localization needs, please contact us at info@lingoport.com, call 303.444.8020, or complete the quote request form.