Posts

Achieving the Happy Path: The Transformation of i18n and L10n for Agile Development

The internationalization (i18n) and localization (L10n) happy path for software development brings i18n and L10n features and requirements of a sprint or release together with no exceptional errors and no organizational friction. That is a bit of a twist on the Happy Path term used in QA, but I’m appropriating and bending as there’s no parallel concept for software globalization. The traditional agile i18n and L10n path is full of brush, rocks, and detours. There’s much we can do to clear the way.

Reasons why i18n and L10n and Agile development are traditionally not graceful pedestrian partners include: human time-delaying processes, limited understanding of i18n among developers, lack of, or ad hoc automation, delayed i18n and L10n QA, vendors and resources which are outside of the development team’s direct control and human errors that add up to blow out timelines. In Lingoport’s own industry survey, which is weighted toward localization savvy participants, only 6% felt they had a strong agile i18n/L10n process in line with their development teams.

Why It Matters:

Markets outside a company’s home country often represent some of the greatest opportunities for growth and stability. Agile development, with its focus on targeted scope and frequent product updates, has a different cadence than traditional software localization, QA, and i18n review, which historically could take weeks or months per release. The impact is that the same delight of frequent updates home users enjoy might not be presented to global customers, with only quarterly or less frequent updates.

This is a competitive weakness. But there’s more to it. If i18n and L10n fall outside of the regular cadence of development, they are by nature part of the backlog. Any bug fixes, file changes or localization updates now involve revisiting code when the developers have moved on to their next efforts. By far, the most efficient and least expensive times to find, fix and update are when the developers are in the code working on a feature and not later. This is one of the important credos of why agile development is embraced in the first place.

Definition of Done:

I18n and L10n are attributes of development, and unless specifically being performed on an application for the first time, they should be part of the definition of “DONE”. That’s no different from other requirements, like security or usability. If you think of i18n and L10n this way, you naturally need to look at how to measure, track and process i18n and L10n in parallel with feature development. You also have to consider how to do it at scale, over multiple teams and possibly over multiple products. Looking at i18n and L10n in this way makes it very clear that automation will help substantially in the achievement of the happy path for agile global software development.

Automation:

Early on in the broader adaptation of agile software development, sprints were typically three to four weeks. Now two weeks and less seems to be the norm. Much of that compression has been made possible through automation. Git, dashboards and coding quality checks take center stage here. If we let computers do what they are good at, people can focus more on where they bring the most value.

When it comes to i18n and L10n, consider that a SaaS product is often likely to have perhaps 10+ developer teams. Now think of 10 more products, all with two-week sprints presenting many small changes, spread over various parts of product source code. It gets more complicated if the product architecture uses a micro-services strategy, often with hundreds of source code repositories. With the pressure of sprint timing, it’s no wonder there’s a disparity with how localization actually gets performed and interfaces with development. It’s also no wonder that i18n and L10n bugs tend to pile up over time.

Automation can streamline multiple parts of the i18n and L10n process, making globalization a measured and easy part of the development process; but the minute you have to wait for someone to gather files, send or read an email, search to fix a problem, run a script or FTP an update, file an unspecific bug or update a translation, you have built-in process friction that is likely to break that release cadence. Lingoport Suite changes that for developers and L10n stakeholders.

Developers and i18n/L10n:

Globalyzer SummaryI18n is a vague software requirement. There are some obvious best practices, like the avoidance of embedding strings in your code (obvious, but it still happens), and less obvious issues (i.e. string concatenations, not passing locale into a method, date/time issues, encoding issues, programming patterns that will negatively impact localization and more).

This is no different than any other quality requirement, like security or even automating bug checking. The closer you can get to when the code is being written, the more efficient it is to correct a potential problem in terms of time, development velocity, cost and your definition of done, not to mention the closer you will be to achieving the happy path. Lingoport’s Globalyzer will present i18n issues right in the developer’s IDE (Development Environment) and/or the checks can be automated on pull requests/code check-in. I18n (and L10n) issues are presented on a dashboard for each repo making i18n and L10n status accountable. It’s a fair bet that individuals and teams will not want red marks on that dashboard in association with their code. What gets assisted, measured and visible gets done.

Developers also shouldn’t have manual tasks regarding L10n. Lingoport’s Resource Manager checks for changes to resource files (many types), checks the files for basic quality issues (i.e. no duplicate string IDs, missing curly brackets and general format issues – 40+ checks) and automatically packages and sends those files to the company Translation Management System (TMS) or to a localization vendor portal directly. When the localization files return with translation updates, they are again checked and if there are no critical errors, they are automatically updated into the repo for testing. All this is clearly displayed and tracked in the Dashboard, status emails and Lingobot queries. Nobody has to be a file nanny.

GlobalyzerGlobalyzer and Resource Manager come with extensive default detection and filtering for many programming languages (i.e. JavaScript, Java, C# and much more) and resource file types. Globalyzer uses machine learning capabilities to finely tune i18n static analysis to pinpoint issues and eliminate false positive detections. Setting up and performing functions can be as simple as calling Lingobot from within collaboration tools like Slack or even from an IDE.

If internationalizing for the first time, Globalyzer’s Workbench speeds up both issue detection and i18n refactoring. The Workbench is meant for i18n power users. More commonly used by development teams, Globalyzer Lite, runs from within popular IDEs or can be called during check-in via API.

QA and i18n/L10n:

Family Search HomepageQA are the gatekeepers of the definition of done, but they need a clear path to measure quality. As developers update interfaces, Lingoport Resource Manager automatically updates changes with pseudo-localizations that can be used to test for language and locale requirements without needing to speak the target languages. Pad characters with target encoding, with a clear beginning and end mark, are added to strings with controllable expansion depending upon target locale requirements. Testers can see quickly if there are problems.

When problems occur, they can be traced back to where they occur in the source code, rather than limited to describing an issue. That’s less time hunting for the issue for developers, and a more efficient process overall in pursuit of the happy path of software development.

Localization Managers:

If localization managers and L10n teams (always understaffed) don’t have to chase down files, updates, and problems, they can instead concentrate on vendor relations, project management, interacting with development, marketing, and in-country teams. These are higher value tasks.

L10n Managers can see the process status readily over many products and repos where teams are doing their work. Having a system and a process also helps Localization Managers to be in control of the quality of their deliverables and product destiny. Most Localization Managers would rather be spending more time on high impact initiatives, such as coordinating global teams and building global strategy, than i18n and L10n bookkeeping tasks.

Localization Vendors:

Agile development presents localization vendors with business issues. It typically means many small localization updates over lots of repositories. Consider that one repo has 16 new words, another has 42, another 116, and so on. The minute a vendor has to deal with any file inspection or formatting issues, the vendor turnaround mandate is difficult. Localization file engineering can’t be absorbed over small word counts. If the software development customer is automatically sending files that have been inspected, then the vendors can cleanly deliver the translations, repeatedly. With our process and using our software, we often see i18n, L10n and respective QA turnarounds go from weeks to under three days, which is critical to keeping i18n and L10n within the definition of done.

Linguistic QA (LQA):

Translation has its own set of quality issues involving context. Words between languages often don’t map a clear transition of use case, with one word equaling exactly another from language to language. This is why we have Linguistic QA, which can be performed by an outside vendor as well as from input from in-country teams.

Traditional LQA again falls outside of sprints. The normal process is to go through the interface and when a problem is found, the LQA team member makes a screen print showing the work to change, with a suggestion filed into a tracking system. That suggestion has to be reviewed and confirmed and then needs a localization engineer or developer to find and update the file and word in the source that corresponds to the update. Again, the usual process involves a clumsy multi-party human set of problems that take time outside of sprint schedules. Instead, Lingoport’s InContext QA lets a reviewer see translation in context with the running application, click on a message to change it directly, input the new word(s) along with any bug reporting notes and submit it for approval. If approved, it can pass back through the TMS or vendor portal for translation memory update or management as needed. No more screenshots, file sleuthing and slow processes. It’s fast and helps teams be reactive to in-country stakeholders. It’s brilliantly simple in practice.

The Happy Path:

I18n and L10n should be part of the happy path of globalized software releases. That is, by using automation to streamline the processes computers are good at performing, we compress i18n and L10n into each sprint and release.

There may be cases where outside issues, like a vendor delay or in-country LQA delays force some delivery of a well-localized product beyond a sprint, but that can have a contingency plan before releases, as the updates can be automated into the source code. That becomes the less happy path, but it beats letting i18n and L10n bugs pile up.

Using the benefits of automation, precision issue checking, metrics and visibility will make for a faster and higher quality product delivery for worldwide customers. That matters for your customers and worldwide stakeholders as well as for your company’s bottom line.

How to Identify an Internationalization (i18n) False Positive | Lingoport

What is a false positive

‘False Positive’ is a common term used when dealing with any automated checking system when an error is reported and the user deems that it doesn’t need to be fixed. You have likely run across a false positive or ‘false alarm’ when working with a grammar check in a word processor.

False positives occur for a few reasons. Software is complex, and it can be safer to over-report than over correct. When measuring complex conditions there will be instances where something that would be an error to one person would not be an error to another. Initially, it needs to be reported. As reporting is managed and controlled, the ease of use with the error reporting will increase. It is expected that users understand and address false positives to make the most of whichever system they are working with.

What is an i18n false positive?

There are some quirks that set i18n (internationalization) false positives apart.

False Positive Example

False Positive Example

It can be difficult to locate a false positive when it relates to an issue but doesn’t actually identify a problem that needs to be addressed.

False Positives vs Issues

Software internationalization rule sets are broken down into 4 categories of detection types:

  • Embedded Strings – Any hard-coded string in the application that will need to be translated.
  • Locale-Sensitive Methods – For example, Date/Time, Encoding, or String Concatenation methods.
  • General Patterns – For example, hard coded fonts, encodings, or date formats: ‘ASCII’, ‘ARIAL’, ‘mm/dd/yy’.
  • Static File References – Application references to static files, some of which may need to be localized.

How to fix an i18n false positive

Any quality automated reporting system will have a way to identify similar false positive patterns. A simple example would be if a grammar check was identifying Art as a word that shouldn’t be capitalized in the middle of a sentence. Despite this being the name of someone commonly referred to in the user’s work, the user would identify the error and tell the system to stop reporting the false positive.

When addressing an i18n related false positive in Globalyzer, Lingoport’s i18n software that identifies and fixes i18n issues during development and enables users to eliminate i18n technical debt, new rule filters need to be created. Doing so requires filling out a simple form.

String Method Filter

A more technical overview of Globalyzer’s specific requirements for manually addressing false positives can be found here

Rule filters help by identifying patterns within the reporting system and refining them to the user’s specific requirements. Individual issues can be flagged for removal at the user’s discretion as well.

What if this could automatically be solved?

To achieve seamless global software development that incorporates i18n into the development process itself, it’s necessary to address the complexities of false positives and to learn to manage them efficiently. However, manually checking i18n false positives is simply too cumbersome for today’s fast-paced agile development.

Lingoport is excited to announce we are fixing this problem with Machine Learning!

The power leveraged from machine learning is more complex than simply writing rule filters automatically. Soon i18n error reports will become dynamic documents that allow any organization to spend less time identifying errors and more time optimizing the product.

Ensure your team isn’t wasting time while internationalizing software for the world market. Watch the recording of our machine learning webinar, and discover how machine learning makes i18n false positives a thing of the past.

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

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.

2013 i18n & L10n Conference: What to Expect, Part 2

The Second Annual Internationalization and Localization Conference is coming up in just over a month!2013 i18n & L10n Conference To prepare everyone for the March 14th event in Santa Clara, California, we will share what to expect from many of our exciting presentations in the weeks leading up to the event. This week we look at a few Agile localization-centric presentations. Agile is a big topic here at Lingoport. In fact, we’ve dedicated an entire resource section just to Agile localization. Learn more at https://www.lingoport.com/resources/agile-localization/

First, some General Information:

Date: March 13-14, 2013
Location: Techmart Meeting Center, Santa Clara, CA
Training: Internationalization training will be held before the conference (see curriculum).
Hashtag: Stay up to date with #2013i18n


Session B4: Sprinting to the Finish: Seven Tips for Successful Localization with Agile Development

Emma Young of Acclaro shares how to successfully integrate localization into an already rapid process of Agile development. Young, the U.S. West Coast Operations Director for Acclaro will share seven practical tips learned from her 15 years of localization experience.

For more on this presentation and Emma Young, visit the official Internationalization and Localization Conference page.


Session B5: Going Global in the Age of Agile Translation: Smartling Accelerates HotelTonight

Andrey Askelrod of Smartling is joined by Russ Taga of HotelTonight to discuss how the two companies collaborated to bring HotelTonight’s app to French, German and Spanish markets through an Agile translation management system. Askelrod, the CTO at Smartling comes from a background of maintaining eCommerce platforms in a number of languages. Taga, the VP of Engineering at HotelTonight, a mobile-only start-up focused on finding last-minute hotel deals.

For an outline on this presentation, read Russ Taga’s blog post on internationalization and localization planning, tools and process: http://engineering.hoteltonight.com/internationalization-and-localization-plannin

For more on this presentation and the presenters, visit the official Internationalization and Localization Conference page.


B6: Seven Tips to Maximize the Value of your Translation Memory Assets through a Transition

Join Adam Jones of SimulTrans as he presents how companies may push through the move to Agile, and leverage the value of translation memory assets. As COO, Jones oversees SimulTrans’ worldwide operations, including project management, translation, engineering, testing, multilingual publishing and marketing.

For more on this presentation and Adam Jones, visit the official Internationalization and Localization Conference page.


Early-bird registration for the conference ends soon, and we are expected to sell out! Register at http://www.regonline.com/2013-internationalization-localization-conference

Lingoport Resource Manager Released

Connecting Development and Localization, New Technology Automates Translated File Management

Today, Lingoport announced that it has released Lingoport Resource Manager (LRM) to support development projects in their localization efforts. By optimizing the manual and often error-prone process of resource file management, LRM effectively bridges the gap between development and localization, ridding the two areas of unnecessary testing iterations and file confusion.

In a press release sent out today, Lingoport President noted:

 “During our product research for LRM, we saw great demand for an automated resource manager solution yet no commercial product was available. Localization and engineering teams talked about the difficulty in keeping up with changes and even delaying global release versions because of the management and integration overhead. Our solution allows localization managers and project engineers to automatically view changes right at the build/source management level, prepare those files for localization and then reintegrate them back into the product build when translated, along with quality and error checking in every step. LRM particularly helps agile teams with complex applications in keeping up with development changes and translation processes. It makes globalized products easier to keep up to date for every market.”

Lingoport Resource Manager represents the next step in answering how Agile and localization can co-exist. So often we have heard at trade shows and conferences that the two were not made for each other and many outdated localized versions of projects were released without proper translations implemented. This conundrum inspired months of research and development and we are happy to bring our solution to market.

Watch this introductory About Lingoport Resource Managervideo detailing the processes that LRM automates.

For more details on Lingoport Resource Manager or to request a demo, visit http://Lingoport.com/LRM or download the white paper detailing the business case for LRM.