Posts

Throwing it Over the Wall

Don’t fall into this simple trap when internationalizing for the first time that can cost years of work and millions of dollars! Our friend Steve, from Plodding Tech. was subject one such story.

Steve knew Plodding Tech. needed to expand their market reach, but he felt his team was too busy to tackle the large-scale project of Globalization. His assumption was that it would be simple string refactoring and translation work anyway. The presumed solution was to reach out to a low-cost outsourcing firm, Raindrop.

It seemed like a cost-friendly solution when it was initially pitched.

Once Steve threw the globalization work over the wall he felt like Plodding Tech. would be moving into the global marketplace in no time.

It was a couple of months before Steve realized his outsourcing firm was learning the intricacies of internationalization (i18n) for the first time. Every couple of months his contact at Raindrop changed as the firm was dealing with a heavy staff rotation.  Steve found that despite outsourcing he was acting as a manager of Plodding Tech.’s i18n efforts. This was exactly the effort he was trying to avoid by throwing it over the wall. 

The outsourcing firm simply didn’t understand what Plodding Tech. was about and what their software brought to the world. What’s worse is they simply didn’t have the ability to quickly react to messaging changes or detail corrections across the target locales in a timely manner. Even after two months, there we still many embedded strings

Often mistakes were overlooked and code drops from the outsourcing group were resolved months after their due date. This was frustrating as Steve was making weekly efforts to advance within the domestic market.

As time wore on Steve felt less like he had hired an outsourcing firm but paid for an assortment of entry-level contractors to tackle a specialized job.

Months became years, and when evaluating the project Steve came to a harsh realization. Even though they started out thinking the solution would be cheaper, little by little, they ended up spending $750,000, not including their own time spent trying to manage the efforts. The outsourcing firm had not developed a methodology to get through the i18n process. There were still embedded strings, application components that hadn’t be updated, Locale frameworks were insufficiently implemented. There was no clear definition of complete.

His own team had moved ahead with several versions and now he had a forked development effort as the i18n had never been well tested, had unresolved issues and so hadn’t been merged back into their code.

That was 3 quarters of a million plus 2 years of phone calls, emails, meetings, and stress. In addition, 2 years of lost market potential.

Steve was burying his head in his hands. This isn’t right, i18n should be creating new revenue streams, not cutting away from the bottom line.  Steve needed to try something new…

Steve needed experts.

When Steve started looking for i18n experts he quickly stumbled upon Lingoport, as anyone reading this article has. After laying out the scope and details of his project Lingoport was able to complete the work for Plodding Tech. in a few short months because our methodology is already in place.

Lingoport’s software was put in place. A list of bugs and issues found in the code could be methodically burned down, tested and completed. His team could work in concert with Lingoport’s services.

Rather than working hard to manage the outsourcing firm Steve found Lingoport came to him knowing the right questions to ask to get the job done and were addressing i18n concerns he didn’t know existed.

Now I’m sure you’re thinking Steve and Plodding Tech. are made up, and you’d be right their name has been changed to protect the innocent. However the 2 years wasted, and the spent dollars were all too real. Don’t let your company face the horrors and losses of throwing i18n over the wall.  


The State of Continuous i18n & L10n Survey Results

Webinar – Continuous Globalization

Complete the form below to watch the Continuous Globalization webinar.

It’s challenging to keep localized releases in sync with software development – particularly for agile development. Keeping up quality and release scheduling is an old problem, which is why methodologies like agile and processes like continuous integration have evolved. Software Globalization practises, including internationalization and localization for each sprint and release, will benefit from an automated, visible and managed approach.

Localization impacts global releases in time, cost and quality, due to:

  • disjointed and manual processing.
  • inherent friction between teams.
  • processing overhead and manual file exchanges.

Organizations adapt, using spreadsheets and perhaps in-house scripts to move content around from source code. The work gets done, but almost without exception, we see great opportunities for improvement. Engineers and managers become bookkeepers for files, versions and updates, often chasing down one another. Nobody likes that.

Integrating development, internationalization and localization has become a bright spot for increasing competitiveness and profits for many companies. The right systems can keep global release management proactive and easily in tune with what the development team is working on.

Continuous Globalization

Continuous Globalization by LingoportIn this webinar, we discuss how to remove disconnects and bottlenecks in globalization. We’re calling our vision Continuous Globalization. In Continuous Globalization, development, localization, QA and management are brought together in a system that promotes global visibility, accountability, measurement and no delays or manual handoffs between developers and source code, localization teams, translators and back again.

Join us to understand more about what Continuous Localization means for your company and the industry.

You’ll learn:

  • How to bridge gaps in understanding between development and localization
  • How to make internationalization and localization proactive in every sprint
  • How to seamlessly get localization done, in complete sync with development and QA

We’ll be doing this by applying the Globalyzer Suite of products, and showing working solutions (not just concepts) with companies like yours.

Who should attend:

  • Localization managers
  • Development managers
  • Program managers
  • Product managers

Complete the Form to Watch the Recording

  • This field is for validation purposes and should be left unchanged.

What is Continuous Globalization?

Continuous Globalization

Click Image to Enlarge

Update: Check out our Continuous Globalization Resource Page for more information.

Agile development has changed localization tasks dramatically as software changes faster but in smaller increments. It’s easy for localization to fall behind, as there are all kinds of management and manual task overhead as files get moved around and updated. We believe that some of the biggest globalization efficiency gains for software companies to realize will be in systematically and continuously integrating internationalization and localization with agile teams.

To address systematic solutions, we’re proposing a new industry term: Continuous Globalization. This encompasses systems and process for integrating internationalization (i18n) and localization (L10n) continuously into software product development. The key here is automation. Not necessarily of the actual translation via some machine translation magic, but managing legacy and new development for globalization issues and moving files for localization from the build to the translator and back again in a very visible and verified manner.

To do this, we automatically monitor software code repositories for i18n and L10n changes and issues/violations.

Continuous Globalization features include:

  • Visibility – Dashboard measurement and drill-down of i18n and L10n violations and changes via static analysis of source code repositories including tools for fixing problems early during development
  • Automation – Automated analysis, verification and exchanging of localization resource files from the build to translation (or translation management technologies) and back again to the build for staging and linguistic QA
  • Metrics – Tracking progress, coding quality, translation timing and more so that you can plan and improve

As you add and update features and locales to your software, you have an automated framework for faster, trouble-free global releases.

Why Continuous Globalization is important:

In practice, most software development endeavors treat localization as a delayed and often manually managed process, outside of ongoing sprints and releases. This is contrary to agile and good software development management practices.

Many if not most companies depend on development & QA teams to manually remember to check for i18n and L10n issues, while meeting other primary release objectives. Developers must  gather resource bundles for localization and  hand them off to localization, which naturally puts the workflow of development and localization at odds. The localization team is forced into reactive management, rather than proactive planning as they really have little visibility to what’s ahead. There’s all kinds of “bookkeeping” issues around managing what’s changed, not missing files, getting it out for localization, then putting it back in the source code. By nature, this delays the whole process, lends itself to handling errors later when the teams have moved on, shortchanges QA efforts and delays localized releases. It just takes longer with all those human processes. It’s costing you time, headcount, cleanup and it impacts the global imperatives of your company.

Lingoport has traditionally focused our product and services efforts on the i18n part of the effort. We’ve seen that there’s so much hassle involved in the development to localization interface and lived the problem ourselves when performing big i18n services implementation. Last year, we released Lingoport Resource Manager and Globalyzer Express to combine both internationalization and localization objectives. Now we’re seeing the solution in action.

Here is feedback one developer gave us:

“When I first started to work with language support I thought we would be lucky to have 80% translated strings in the product due to the complexities. Everybody is very pleased with the near 100% translations we got.”

We’re particularly proud of this. Most developers are not often kind with their feedback for localization in general.

In discussions around Continuous Globalization with localization managers, I am frequently asked if I intend to replace translation management systems. The answer is no. Continuous Globalization works even better when the two are connected.

I’ll be leading a webinar on August 27th that will detail what Continuous Globalization looks like with examples. I hope you can join us.

-Adam

PS You can register by clicking here and completing the form.