In March I attended and presented at the first Worldware conference, which took place in Santa Clara, California in the heart of Silicon Valley. I became really excited about this conference as it proved to be the first to directly target business issues around software internationalization and globalization. Too often in other conferences, the focus is very low level on technical issues, while missing greater business planning and operational issues that affect every organization that looks to build and maintain world-ready products. In fact, that issue had been a long running annoyance for me when attending conferences like Unicode and LocalizationWorld. So I was eager to get involved in Worldware and sat on its board as well.

The conference had outstanding material, and featured various business leaders from well known world software brands. The downside was that the conference was not particularly well attended. There were probably a total of about 70 people there, including speakers, but at least we all got to know one another. Presentations featured executives from companies like EMC, Microsoft, Linden Labs, Oracle, Mozilla, Sun, Adobe, Yahoo!, Intel, various industry consultants and of course me.

Here’s a few items from my notes and memory, in little particular order:

• Don Depalma, of CommonSense Advisory, had some excellent data showing return on investment and overwhelming customer preference for software which was internationalized with locale sensitive language and formatting support. His numbers were of the Holy Grail that managers have been asking for. A big point was that even when end-users are perfectly capable of reading, writing and speaking English, they vastly preferred software in their own language to the point where they made choices and spent more in line with that preference. Don had data broken down even per country. I can’t wait to poach some of these slides.

• Common points were that i18n is an enabler for localization and ultimately revenues. A way to waste a ton of money is to pursue localization before you’ve properly internationalized.

• Organizations like Mozilla and Linden Labs (Second Life) are making great use of crowdsourcing to enable new features and localization. So if you have a product which has an emotional type of rabid following, crowdsourcing is a relatively new form of getting help, though it needs its own adaptation for management.

• Some companies, like EMC, must simultaneously ship for all top tier locales when releasing new products. So globalization isn’t an afterthought.

• Executives don’t understand internationalization but understand the cascading effect.

• Invest in internationalization expertise. Too expensive to “wing” it.

o Empower product teams

o Create i18n boot camp training

• Some companies demonstrated that they have built whole organizational frameworks to support internationalization. Particularly Intel and Yahoo! presented how they are using technologies for automatically auditing global readiness. Happy to say Globalyzer got many accolades.

• There was a lively Agile (extremely popular development methodology) discussion as it relates to internationalization. This is because if i18n is built into the product development from the start Agile works great. When there are Agile cycles and i18n on existing code going on simultaneously, both efforts are very unlikely to synchronize well. Lots of reasons for this, which would probably make a great future article for this newsletter. This issue came up multiple times and Tony Jewteshenko gave a whole presentation session on it (but I wasn’t able to attend that one).

• It’s extremely difficult to take back a language after you release for a particular market. So consider that request for your software in Klingon carefully.

• How you communicate around the world will empower your organization.

o Brand recognition

o Market Share

o ROI

• I presented along with Daniel Goldschmidt on how to get an i18n effort going

o Technical buyer, vs. Management objectives

o Need to get a good plan for budget approval first, design second

o Showed Globalyzer 3.0 and scanned some open source code

o Demonstrated a project plan

o Daniel broke down i18n projects into a 3 phase approach

• Transportation – moving data from A to B

• Application – doing something with the data (e.g. sorting)

• User Interfaces

o Then we both talked about keeping software world-ready and answered questions

• Kamal Monsour of Monotype Imaging gave a most informative presentation showing intricacies of digital fonts in languages like Arabic and Hindi.

• I was on a panel along with Ed Watts of Oracle and Mike McKenna from Yahoo! on Assessing and Quantifying efforts. Ed emphasized the role of pseudo-localization. Mike was his usual incredible reservoir of information and experiences both organizationally and on the technical side in supporting i18n. I talked about how we essentially have had to learn to estimate and execute internationalization projects and still make a profit, and that’s why we’ve created tools and methodologies to do so.

• Aaron Marcus of Aaron Marcus and Associates gave a presentation on cross cultural user-experience design showing many cultural differences, certain scales by which cultures accept power hierarchies and how that shows up in site design.

• Mike McKenna showed a fabulous presentation on trends in internationalizing which featured several i18n initiatives at Yahoo! As a bonus, I got a Fight Mojibake sticker (ghost characters), which is now on my notebook. In particular, they work to get people enthusiastic and understanding that they are creating products for the world. He also talked about how his team supports i18n with tools like Globalyzer. Thanks Mike.

• Barbara Burbach of Cisco talked about staffing models, including outsourcing for i18n and l10n. She felt i18n outsourcing for an existing product was a good idea, as it keeps the core development team focused on new features. For new products being internationalized from the beginning, she preferred in house engineering.

• Tex Texin (i18n Guy) discussed how he has worked with various teams to promote internationalization, and how decisions were often affected. He also gave Globalyzer a nice recommendation. Tex was formerly in charge of internationalization at Yahoo! and NetApp, both of which are Lingoport customers. Thanks Tex.

I’ve missed a ton in this quick summary, as I haven’t managed to master being in two places at once and couldn’t have attended all the sessions.

One very potent way to make software globalization fundamental to a company’s mindset is to make internationalization a fully integrated and automated part of software development practices. There are all kinds of tools, checkers and environments to help developers create interfaces, access and transform all kinds of information buried in databases, support coding constructs, manage memory and perform application modeling. With that in mind, we’ve been hard at work with a major new Globalyzer release, clearly aimed at supporting entire development departments and enterprises, automatically using batch processes on servers to monitor internationalization progress as well as on the desktop where issues can be individually examined and fixed. While that has always been our aim, we’re now getting there in more robust ways that track internationalization status over time over multiple programming languages and even over multiple products.

For those non-developers reading this, let me explain what I mean about automation in this context. When engineers create code, they generally all submit their work to a code repository. This repository provides version control so that when multiple engineers are all working together, they can check code in and out and merge together all their changes. Then the code has to be put together and built. This build process usually occurs on some interval, such as nightly or even on a continual basis. During this automated process, you can also automatically check for many other issues like performance, load balancing, and I’m proposing that this is a great time to check on internationalization/localization readiness by running tools on the code automatically as a batch process, which then tracks issues via reports. Now counting issues is one thing, but you can go even further by showing exactly where a problem exists in the code, along with the context of the errant issue. That information can then be brought forward for quick review and fixing.

Two companies which come to mind, doing this very thing are Intel and Yahoo. Michael Kuperstein of Intel, presenting at the WorldWare Conference in March, reported how his team developed their own internationalization toolkit a few years ago and have integrated it into many of their automated build processes. That automation has made internationalization an important and measured component of their ongoing development efforts. By Mike’s own admission, he would have used Globlayzer had he known about it years ago.

Mike McKenna of Yahoo also reported at WorldWare that his globalization team is using automation, in this case Globalyzer, to measure internationalization benchmarks on development teams.

On the localization product side, there are multiple tools for different aspects of managing words. But when it comes to products which support an enterprise in their software internationalization efforts, there is a pretty empty playing field. Aside from some very simple string externalization utilities in a few development environments and frameworks, our Globalyzer is simply the only commercial software I know of that can automatically monitor development over time over a wide range of programming languages, while also stepping entire teams through internationalization fixes in large amounts of code.

I’ve said a few times in my columns that I’ve found that it’s quite powerful to embrace the management principal that whatever gets measured gets done and improved over time. So it follows that one of the most important aspects of any software development undertaking is that you measure desired outcome over regular intervals. If you just hope that it will all come together in the end, you always end up late and over budget. That is ultimately behind the agile and extreme programming development movements, in that you make more frequent intervals of measurement and goals. But it’s not so easy to track something like internationalization, either as a project where you are refactoring software for new globalization requirements or even for ongoing development. Consider that developers are typically over tasked, and often distributed across time zones and continents. Then factor in that internationalization can be quite subjective to a particular development task. Plus internationalization is a fuzzy thing, in that it is tailored to requirements, technologies and special cases. So what development teams grapple with how to handle it, and make their way through the task by brute force – or simply postpone or avoid internationalization whenever possible. Issues get missed, and if you’re lucky, you have an iterative process during localization to fix internationalization bugs, which is a very expensive and time consuming path. Or worse, development ignores the issues and calls it a localization problem.

I spoke with a company in just that situation last week. They were upset with their localization provider for poor quality, but when we examined some of the issues, there were also extensive internationalization mistakes that were sure to break localization context and execution. These included missed strings and extensive string concatenations. Had they been monitoring these efforts all along, and been clearer on internationalization requirements, they would have had better results and a clean release. The biggest costs to them were poor market entry, customer dissatisfaction and complaints from their distributors and sales teams which had to overcome a poorly localized release. Now I also feel that as vendors we have some responsibility in taking care of clients and not selling them a solution that risks poor quality and a weak market entry, so some blame also goes to the localization provider. But I hardly know what really happened, I was just there to offer help in picking up the pieces. Clearly that’s an expensive route in many ways.

Remember, internationalization is often run by a different crew than localization. Software developers are upstream from localization, and they are sometimes all too disconnected from a final localized product releases. Localization is often someone else’s problem and engineers are focused on getting a release out with all its new features. They don’t know what they don’t know, which is only human. That leaves localization teams waving their arms around trying to get the developers to build software right the first time. And those teams likely have no way to measure if the product they are tasked with for localization actually passes internationalization muster, until they go through localization testing. Again that’s very late and expensive in a software development process, and more often than not, localization testing tends to be underfunded and vendor dependent. You’re going to have trouble finding everything. So for localization teams, what I’m suggesting is to consider a kind of automated litmus test. When code comes to the localization group, scan the code for internationalization issues, and consider what’s found. The technology is now there to do this in detail and examine each potential issue, quickly and easily. So at the worst case, you can at least have engineering fixing internationalization bugs during the localization process rather than when it’s far more expensive.

Again, anything that measures and sheds light on the situation will also have the result in making improvements. So if you want well globalized software, better start measuring how that code is developed, not just what it’s costing to localize it.

P.S. I’m thinking of writing a column on funny ways people fell into the localization business. If you have a good story you’d like to share, please contact me!

1.) Database enabling of Globalyzer reporting – Globalyzer 3.0 comes with its own database, or the option to connect to your current database. You can compare Globalyzer results over time, track individual internationalization issues from scan to scan and share scan results and fixes with your fellow developers.

2.) Command-Line integration with ANT and automated processes – Command Line, though less exciting to look at, offers tremendous power in supporting entire teams of developers in monitoring and measuring internationalization. With Command Line, Globalyzer can now become the benchmark for localization readiness. We’ve included a wizard to help teams get Globalyzer up and included in automated processes, like a nightly build.

3.) Easy sharing of scan results for fixing i18n issues – Scan results can be quickly and easily loaded into Globalyzer’s GIDE desktop interface so that teams of developers can step through and fix internationalization issues efficiently.

4.) Scan extremely large volumes of code in one pass – In previous versions of Globalyzer, when you wanted to scan large applications, you needed to break up the source. Now you can point Globalyzer at literally millions of lines of code at a time.

5.) Batch scanning across multiple programming languages – Internationalization issues are quite different among programming languages, requiring Globalyzer to use different engines to get the best results. We’ve now allowed you to combine scanning engines to batch process code bases with multiple programming languages. For example, for JSP’s you can combine HTML scanning with Java scanning in one effort.

6.) Keeping track of issues you want to ignore – Besides Globalyzer’s great filtering capabilities for isolating complex internationalization issues, Globalyzer now tracks your code line by line, so that you can elect to ignore, or even emphasize issues, and track and revisit them without Globalyzer needing to insert its own comments in your code. Keeps things clean.

7.) Faster performance – Though how fast Globalyzer scans source depends a lot on the code you are scanning, Globalyzer is running on well over a million lines of code in about the time it takes you to go get a cup of coffee.

8.) New Look on the Interface – we rewrote much of Globalyzer’s U/I, giving it an updated look. The biggest reason we’ve done this is to prepare for good stuff we are planning for the soon to follow 3.1 version, but for now, we think you’ll like it.

9.) Bug Fixes – we’ve cleaned up issues to keep you on your way finding and fixing embedded strings, locale-limiting methods, functions and classes and programming patterns.

10.) More Programming Language Support – Globalyzer already supports a wide variety of programming languages, and we’re formalizing support for a few more.

11.)Tighter Integration between Globalyzer’s GIDE client and server accounts on Globalyzer.com, so you can quickly change your rulesets which control Globalyzer’s behavior and share changes with your colleagues.

Sign up now for the Globayzer 3.0 beta in March – contact beta@lingoport.com with your name, company, email and phone number.

Chances are you’ve seen corrupted data, but perhaps didn’t think too much about it unless you’re a localization engineer. Most people see it first in their spam, coming with promises of Euro-Lottery millions or other nefarious offers. The corruption evidence is in the square boxes or random nonsensical characters that fill the subject heading or email body, if you haven’t deleted it already. What’s happening is that somewhere along the way, or in your mail client, the character encoding the message is written in is not being supported. Obviously you wouldn’t feel very confident using a product, site or system that suffers this same issue, so it’s a clear defect. Sometimes you even see it when everything is still all English, most notoriously when somewhere along the way the software system you are using can’t process a simple apostrophe.

Remember that all data on computers ultimately breaks down to zeros and ones. These values are then interpreted to form characters and then strung together as words or symbols. Corruption occurs when the interpretation of the encoded zeros and ones does not form the intended character. For example, the application thinks the encoding of a character is ISO-Latin 1 rather than UTF-8 and so displays the wrong character. We have run into several internationalization services customers over the years that have inadvertently corrupted character data buried within large databases. Here’s an example of how bad this can get:

Imagine your company is a world leader for building heavy machinery and construction equipment. You have a massive parts catalog. Over time, an unknown amount of data has experienced character corruption. The characters are no longer humanly readable. They look like gobbledygook. Or, you have a complex online customer management system with a large database of users and corresponding account information with broken character encodings sprinkled throughout.

In each case there are too many occurrences peppered throughout the data to review and manually decipher what the original intent of the content was. You can imagine the panicked conversations when the broken characters are discovered. “Oh σηιτ, look at this! How the φυχκ are we going to fix this!”

Often the instances are too scattered and it’s too difficult to roll back to previous versions of the data, as everything new would be lost, and it may not be known just when the character corruption might have started happening.

The corruption occurs in the first place when there’s some source in the application or process or reviewing data breaks the encoding. For example developers may have implemented a web page form that isn’t properly set up to return data in the correct encoding. Another possibility is that someone manually imported new data into the database, but used an editor that is not set up to handle, say UTF-8 encoding. The culprit might be as innocent as using Notepad incorrectly.

At this point, this conversation has happened with clients several times a year, and in every case, these clients already happened to be working with us in some capacity, whether on service projects or licensing our Globalyzer software. I suspect the problem isn’t actually all that uncommon. So we finally decided to take some of the advice I’ve been trumpeting in this column and productize some of our solutions. At the time of this writing, we haven’t decided on a product name yet, so we affectionately call this solution The Decombobulator. We’ll probably officially release it as something boring like db Ambassador, but we’ll always call it the Decombobulator internally because it sounds funnier. Check our website to find out if humor or practicality wins out (remember that we are probably the only company using an icon of a toilet plunger as part of an interface and utility names like PseudoJudo). In fact, I encourage you to contact me if you’d like to vote on it or suggest a better name.

So here’s how we solve this problem. The Decombobulator runs on your data or database, reviewing characters at the byte level and reporting the results. It then helps you compare character encoding to the intended encoding and then reports, suggests and helps automate the correction back to what the character was intended to be.

Here’s an example using corrupted names from a database which initially had problems with some cases of extended characters:

I’ll add that we’ve seen strings that clients have submitted to their localization vendor which also have the same types of instances of corruption. Often this happens when someone opens a file, just to check that the data is there in the first place, but then saves it again without the proper character encoding settings. The localization firm then has a number of isolated strings, perhaps including past translations, which are now broken.

I’m not illustrating all this as a sales pitch. I somehow doubt we’ll sell very much of the Decombobulator, but for the people that need it, it will be a lifesaver. In fact, much of the development and productization of the Decombobulator happened without my knowledge and even in part against my intentions. One of our team just took it upon himself to take extra time while getting his other work done, to enhance what we had and put it together. I bring this all up because in your business, you likely encounter some problems just like this which are just begging for a repeatable and scalable approach that will make you a savior to your client or coworkers. And if you can repackage it for the benefit of your organization or clientele, you’ve just created a significant differentiating value. That’s what people love to buy, whether it’s you selling your continued employment or cementing a client relationship. This doesn’t mean you learn software development on the side if you’re not a developer. Every process presents its own opportunities.

The economy is rough out there. I won’t bother parroting what you’re no doubt reading. It may be that one of the few bright spots is still the language services and technology industry. I talk to quite a few CEO’s of localization companies and they all seem to be reporting that business is holding up, but they are crossing all their fingers and toes that it stays that way. If I were in the automobile or furniture business in the US, I’d be beyond scared. But the fact is that the entire language computing industry directly connects to helping technology firms make more money. Notice I didn’t say save money. While that’s important too, making money always wins. So the way that we differentiate our industry and for our clients and co-workers is by innovating in ways that get work done faster, better and cheaper, so that someone can sell something more effectively anywhere in the world. And that’s just great business.

March 12, 2009
Noon to 1:15 PM Mountain Time (GMT-7)

NOTE: This Webinar has occured, but we will be providing a recording and making it available. Please register at the bottom if you’d like to be notified when the recording is available.

Attend this webinar and learn as we go through steps to assess and examine a few hundred thousand lines of code. As you might guess, we’ll be using Globalyzer 3.0 to do it, but rather than make this about a product demo, we’ll be working through internationalization coding issues and fixing them. This webinar will feature interactive technical discussions with our architectural team. Our past seminars have always filled up quickly, so sign up soon by emailing webinar@lingoport.com with your name, company and contact information.

Here’s what you’ll learn:

• How to approach internationalization requirements within your large code base
• Auditing your current code base for internationalization issues
• Examining embedded strings, concatenations
• Examining locale-limiting functions, methods and classes in multiple programming languages and database scripts
• How to fix internationalization issues faster
• Building an i18n project plan
• Coordinating internationalization efforts among developers
• Verifying internationalization automatically
• Supporting internationalization across your enterprise on an ongoing basis

Be sure to sign up soon by sending an email to webinar@lingoport.com with your name, company and contact information.

In the past I’ve written about ten tips for managing internationalization projects. Here’s a look at mistakes that I’ve commonly seen repeated on the client side. In our services practice at Lingoport, we often have to council our clients through one or more of these sorts of process issues, which is actually a very rewarding part of what we do. While this list is pretty high level, we’ve seen that the processes involved can set up cascading failures that eventually can have a serious impact on a project’s success. Some apply more to internationalization of existing applications; others can apply to development where internationalization is planned in from the point of conception (still kind of a rare thing, but gaining).

So, here are 10 internationalization process mistakes to avoid:

1. Don’t forget what drives internationalization: Money on the top and bottom lines of your company’s balance sheet. The point here is that the costs of being late or lousy endure way beyond benefits of cutting corners on development. Internationalization happens because of a:
a. New customer(s) sale
b. New partnership
c. Strategic initiative backed by marketing, legal and other types of efforts and investments

2. Don’t assume internationalization is just an older software legacy issue. It comes up surprisingly often that people even in our industry think that internationalization is mainly an issue for older applications. No framework, whether it’s J2EE, .Net, Ruby on Rails, PHP or whatever is new and improved, internationalizes itself. You still need to do all the steps necessary to implement locale and all the associated internationalization practices. Many newer programming platforms do an excellent job of internationalization support, which is great news as you can estimate and execute with a higher degree of accuracy. But you still have plenty of work to do.

3. Don’t assume you can treat internationalization like any other feature improvement when it comes to source control management. With internationalization source control can need an extra step of thinking things through. It’s very typical for new feature development and bug fixing to be going on in parallel to internationalization efforts. However, in the process of performing internationalization, you are going to be breaking major pieces of functionality within your application as you make large changes to your database and other application components. In order for respective developers to work on their own tasks and bugs, you typically need to branch code, often with specifically orchestrated code merges.

4. Don’t assume internationalization is just a string externalization exercise. String externalization is important and highly visible, but the scope of internationalization includes so much more. For example: creating a locale framework, character encoding support, major changes to the database, refactoring of methods/functions and classes for data input, manipulation and output. How these are all approached, varies greatly based on requirements and technologies.

5. Don’t wing it on Locale. Designing how locale will be selected and managed often doesn’t get the amount of thought and planning deserved. How the application interacts with the user, detects or selects locale, and then how it correspondingly behaves is a design process needing input from an experienced architect, product marketing and the development team. This is not an area to be chosen by any one representative by fiat. It’s a whole lot of work to redo locale if it’s executed inadequately for user, business and locale requirements.

6. Don’t create your very own internationalization framework. Don’t even do it if you think you know better. We regularly run into clients who have half-way implemented internationalization using their own homegrown methods for string extraction and locale management when there were already well establish methods provided within their programming language framework or established solutions like ICU. Using these will ensure that your code is far easier to maintain, and you’ll know that thousands of applications have used them successfully before you. No unpleasant surprises.

7. Don’t think that the team internationalizing your software can work without a working build. This seems obvious, but it comes up lots. Without a working build, the developers can’t smoke test the changes they are making. Even if you provide a dedicated QA person, my own experience is that developers need to be able to compile and run themselves to head off problems later. It’s too hard to rely on reconstructing coding errors at a later time and make for unnecessary bug fixing iterations, lost time and poor quality.

8. Don’t run out of money. Internationalization planning often suffers from underscoping. At Lingoport, we have both software and well established methodologies for estimating internationalization, as we really don’t want to ever break this rule and have to ask our clients for more funding. Same should hold true for internal efforts. Lapses in funding can cause expensive delays, as new funding takes more time than anyone imagined to get approved. It also reduces management credibility. And chances are, if you need to ask for more money, than you also need more time, which brings you back to consequences regarding tip #1.

9. Don’t use a half thought-out character encoding strategy. Use Unicode, rather than native encodings. If you have budget and time constraints and you’re only targeting dominant languages in markets like Western Europe, North and South America, you can often get away with ISO Latin - 1, but even for Eastern European languages, go Unicode. Then when you do, make sure your encoding works all the way through the application. And don’t forget that if your customer needs to support worldwide customers themselves (e.g. enterprise software), they may need you to support Unicode data processing even if the interface remains in English. One more consideration tilting toward Unicode is that programming languages like C# and Java already internally pass strings and data as Unicode, so you might as well think about engineering for the world.

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. In our services projects, we always put special emphasis on working through pseudo-localization of not only the interface, but sending test data using target character sets, locale altered date/time formats, phone numbers and more, from data input to database, to reports and so on. If your testers are English only speakers, that’s fine. For example, we have a utility, PseudoJudo in one Globalyzer that puts target language buffer characters surround English strings. You can expand data fields to fit physically longer strings giving room for translation changes in sizing as well as encoding.

11. Bonus Tip: Don’t assume Localization is just someone else’s problem. It’s funny how many of our customers are strictly concerned with software development and don’t actually have anything to do with localization processes. We always work to bring together localization into the internationalization effort. We do this by interfacing localization resources early on, helping them understand the technical requirements and then feeding translators strings that we extract on the front end of projects, so that when internationalization functional testing is done, we are immediately ready to perform linguistic translation testing and ultimately deliver a finished product. This compresses times to global release, while also making for a more fluid process, less programming iterations and higher quality.

MultiLingual Computings’ illustrious editor, Katie Botkin contacted me a few weeks ago, asking me to write my next column relating to the current worldwide economic mess. What can we say about a financial market that nosedived, and at this writing is fluctuating hundreds of points daily? My fear is that by the time this article gets published and distributed, it will be hopelessly out of date due to the latest maelstrom or recovery.

“Politics is the art of looking for trouble, finding it, misdiagnosing it, and then misapplying the wrong remedies” - Groucho Marx

I won’t bother going into various contributing causes and tales of financial greedy miscreants and cronies, but suffer me to say that this situation didn’t come out of nowhere. My wife, who runs Lingoport’s operations, has been telling me for over a year that a crash was coming, as she reads some fairly sophisticated financial newsletters and publications, and thankfully she had us prepared for it. Being an optimist, I wanted to ignore her. So how come, Henry Paulson had to hastily cobble together a 3 page insult to democracy that he sold as the basis for a rescue plan? Hopefully that sort of institutional incompetence will be at least curtailed come inauguration day, January 20th. Enough of my ranting, this article is about the economic effect on our industry and what we can actually do about it.

“Who are you going to believe, me or your own lying eyes.” - Groucho Marx

Firstly, do we have a problem here? I posed a question to the L10N group on LinkedIn asking if members were experiencing any signs, anecdotal or otherwise, of the economy in their work, and if and how that was changing planning. I got a number of very interesting answers, most of which expressed concern, and a consensus reporting business has been quite strong. No one was reporting any actual lost business due to corporate cutbacks, but it was a small and unscientific sample.

Paraphrasing Serge Gladoff of Logrus, “fear often is capable of creating its own reality.” He has a point. He also added that we are in one industry that may actually even still grow under the current circumstances as companies look for opportunities in new markets.

One respondent from France had this to say: “In the long run, I’m still very confident and this crisis will probably help to clean up the actual economy and allow it to rebound on much more reliable basics.”

Michael Gavin, an industry consultant had this to say: “For service providers I believe the strategy for success will be based on their ability to innovate their offerings, their business model and engage with other market sectors outside of their traditional comfort zone of IT and Software.”

I had similar flavors of responses when I asked people about the economy and their business at Localization World. People reported that they hadn’t directly experienced any slowdown in their localization businesses, but admitted it may be early yet to judge things and they were bracing for possible storms to come.

“The milk of innovation doesn’t flow from cash cows” – David Isenberg

This market reaction seems very different towards globalization than the tech crash after September 11, 2001. While that crash was already in motion, the terrorist attack was cliff jump which froze many of my customers in their tracks. Back then, I had only started up Lingoport half a year earlier. I had my first larger i18n construction project under way, which was promptly killed on September 12th. I had the unlucky break that this client served the airline industry. Many other smaller prospects halted their plans as well. All this pain forced me to regroup and innovate, as I had several engineers and few customers. So we worked on the early version of what became our Globalyzer product. Like Michael Gavin said, the situation encouraged and rewarded innovation.

I also suspect this time around, globalization has further matured in terms of the planning mindset of business minds. As companies earn more and more of their revenues from global clients, the emphasis on spending, even within a defensive posture, is likely to include supporting and growing those global revenues. I’m glad we are all ultimately selling revenue growth (if you think you are providing translation, guess again) rather than big cars, fancy cell phones or furniture.

At Lingoport, I always feel we are an especially good bellwether because we focus on internationalization, rather than localization. Internationalization always involves expansion and looking for new opportunities, while localization can often simply be generated by maintaining products over existing global sales networks. Many companies also initially perceive that they can tackle internationalization engineering internally if times are tough, whereas they may be a little less likely to have skilled translators on staff (excepting the erroneous idea that the sales associate is qualified to translate because he/she grew up speaking Spanish at home). When companies are being defensive, new expenses like a large scale engineering effort can stick out on financial projections. One easy way for companies to cut expenses is to just kill budgets on any new initiative. This is at least some logic that I’ve seen in other slowdowns. It can be hard for companies to think about expansion if they are in a defensive position. But what I’ve also seen, is that as financial planning stabilizes globalization needs are still right there, needing attention.

Two opposing real world examples at Lingoport have been one repeat customer who asked us to take on more work and accelerate efforts (more money) and another repeat customer who was planning on extending some work, but got budget frozen (presumably indiscriminately and for an indefinite period) the day he was ready to give us a new order. I asked the expanding company about their corporate mindset, and they were extremely bullish on expanding globally in the face of market adversity and recession. They felt now more than ever was the time to move and grab a growing share of worldwide revenues.

This brings me to what we can all do to help our respective situations. We’ll all be expected to do what we do better, faster, cheaper and more efficiently. I don’t have to act like much of a pundit in saying that. Specifically here are three concepts worth special emphasis:

1) Gross Margin rules: For those of you new to the term, Gross Margin is income divided by net sales expressed as a percentage. It reveals how profitable a company or endeavor is outside of taxes and many other factors which can include research and development and marketing. Gross Margin is so important because it determines the power of your sustainable cash arsenal to do those things that differentiate your company.

a. Whether you are on the client or vendor side – be persistent in finding ways to maximize and measure how any effort you undergo contributes to your company’s gross margin.

b. Remember that if you already have sales efforts going on outside of your native borders, quality internationalization and globalization can’t help but improve your gross margin as your product becomes more competitive.

c. Look to enhance global relationships which positively impact global revenues.

d. On the vendor side, mind your customers, projects and project volume like never before. Work to minimize past due receivables which in turn improves cash. Through very symbiotic methods with our customers, Lingoport has an average receivable cycle of only 21 days. It’s rare for us to have a receivable go unpaid for more than 45 days, and it’s not because we are being pesky.

e. Remember this management truth: what gets measured has a way of getting done, as well as improving.

2) Innovating tasks and processes that are important but not urgent tend to differentiate companies. It’s that extra effort to make product or services that have some repeatable benefit outside of the ordinary that you need to spend some time on. This can be particularly challenging when you are asked to do more with less and flooded with the emergency du jour, but it is also the most important time to reserve attention for innovations. If you can meaningfully improve something that’s “always been done that way” do it. Then note item 1a, and how your innovation saves time/money or reduces the overhang of iterative work.

3) Don’t take the attitude that you know all this and its common sense. You are actually correct, but how often do we really live what we know. Action is its own reward when we follow common sense and make real improvements. So avoid going negative or being overwhelmed by the possibility of future disasters, and live and work like you mean to put “common sense” to good use.

“Don’t worry about the world coming to an end today. It’s already tomorrow in Australia.” - Charles M. Shultz

Note: While this software internationalization and localization training webinar has already occured, you can hear a recording on our localization partner’s site (open’s a new window). Sign up on our newsletter list and you’ll be notified when we host the next webinar, planned for late January/early February 2009.

You can unsubscribe from our newsletter at any time, by following the unsubscribe link at the bottom of every newsletter.

In pretty much all of our client engagement opportunities at Lingoport, we quickly arrive at a common discrepancy in how people within organizations view the decision process for internationalization and localization. On the one hand you have a VP or CEO saying, “We must have this product ready for such and such market by year end!” and on the other extreme, you might have an engineer plotting out her decision process based on technical task oriented details – like locale frameworks, database changes and the like. One mindset is event or strategic driven. The other is focusing on the minutia of the process. Neither approach is wrong, but I always feel the client is best served when both mindsets come together.

When companies internationalize their software, it is fundamentally changing its world view from their status quo of selling what they have for their home market, to adapting software to work gracefully in any language or locale. It’s a strategic vision or customer request that brings this about. Or in many cases, a company may have even been localizing product support information, yet selling software as English version only for many years, and recognizes it needs to correct that weakness. Fortunately for us, internationalization is becoming less of a surprise process as executive understanding of software globalization has been maturing.

Globalization is a hot strategic subject for just about every business conference these days. Competition worldwide is tougher, and overall world demand for software is up, so the globalization impetus is hardly visionary any longer. I like to broadly summarize internationalization drivers as:

• The boss went to a conference/board meeting/gathering and sees that he/she must move forward more aggressively with supporting global software sales
• Or, the company has a big new client/partner/joint venture opportunity, but it requires that the software work in another or several languages.
• A competitor is successfully entering new markets with an internationalized product and the company must catch up to compete
• Or, the company is already quite global but is purchasing another company which is not, and needs to get the software adapted as quickly as possible.
• The company has a global view, but developed software quickly and as such, let internationalization go in favor of getting to market quickly. The product has proven successful and it’s time to roll it out.

The same company, just depending upon the business unit or product team, may fit into some level of all these business drivers.

Executive View

The executive team will be concerned about the balance of issues regarding delivery time, marketing, sales and personnel expenses, setting up offices/distributors/partners, legal and tax issues, and more countered against revenue projections. Internationalization for them is getting the product ready so that is supports revenues, global logistics and strategies. It’s a key part of the deliverable though clearly a means to a carefully projected outcome.

Engineering View

I have yet to meet the VP of Engineering, or any engineer for that matter, which wakes up one morning and thinks, “Gee, I think I’ll internationalize our software because it would be cool!” Engineering is in general over tasked, shorthanded, time critical and primarily responsive to documented marketing requirements. New feature functionality on the other hand, is occasionally trail blazed by engineering even before marketing clearly understands a need. For most engineers, internationalization is revisiting development they’ve already done, and breaking it, only to be rebuilt again. That’s seen differently than a new feature.

Engineering will view internationalization as a technical objective and use case, deconstructing it into tactical steps. As a rule, Engineers are really smart people, so they go about figuring out how to internationalize their code, but often with no or limited previous internationalization experience. So they intensively hit the books and Google. Here at Lingoport, after internationalizing so many applications over so many programming languages, we are still learning with every implementation, but the bank of knowledge has become quite deep. Internationalizing a complex software system for the first time, the engineers will almost certainly miss-scope part of the effort, make some mistakes, endure some poor assumptions and run late. That has the potential to sabotage the plans that the executive team is counting on. This is where at a minimum, getting some educated advice, tools and assistance can be highly effective in meeting broader market release goals and obligations.

On top of that, engineering time is never free or infinitely available though sometimes both these conditions are initially assumed. The development team requires salaries and other support. Engineering production also has an important opportunity cost. Does the team work on new features for their current clientele in markets where they are already strong, or do they take a “time out” on new feature development to engage in a full on internationalization effort? You can rarely have both going on at the same time unless you bring in outside help, with well coordinated project management and a good source control strategy.

I consider it part of our job, when working with clients, to bring together the executive and engineering criteria, so the strengths of both are considered and all stakeholders are educated and can have a predictable outcome. This makes a foundation for stronger individuals, teams, products and companies.