A Smarter Approach to Global Growth

On July 25th, 2018, Lingoport hosted a webinar focused on product strategies for enhancing successful global expansion. The webinar featured special guest Talia Baruch, Founder of Yewser, which helps companies maximize international expansion, accelerating global growth to win adoption in new markets. Talia integrates the cultural and regional factors in product strategy to optimize for discoverability, customer acquisition, engagement, conversion, retention and brand loyalty in international markets.

During the webinar, The Global Product Strategy Playbook of Leading Brands, Talia shared her experiences helping to guide leading organizations ranging from Google to SurveyMonkey, LinkedIn, and VMware achieve successful global growth targets.

Prior to the webinar, we had the opportunity to chat with Talia and to uncover a few of the insights she eventually shared more deeply during the webinar. If you head up product, growth, marketing, or business development at your company, this is an interview (and webinar) you do not want to miss.

Interview with Talia Baruch

Lingoport:

Talia, you have a very long and successful career in internationalization, localization, international product management and global growth strategies. We were curious how you got interested and involved in this field?

Talia Baruch:

Well, the inception comes from my multicultural family background. I’m a product of where East and West meet. My grandparents’ home in Rednage, a small village in England, was called Yewsdene (=the home of Yew, a big ever-green, cross-continental tree). I’ve named my consulting company after it: Yewser (as in Yewser Experience).

Yewsdene represented to me that cross-cultural, cross-border connection I’d absorbed from childhood. I have deep roots in Eastern & Western Europe, Uzbekistan, and the Middle East, so the Silk Road junction, where people connect across cultures and borders to open perspectives makes a lot of sense to me. Yewsdene was the place where post WWII, many of my grandparents’ extended communities  friends and family’ found a safehaven, and where I was fused with profound post war cultural awakening for tolerance values. It simulated me and it made me realize from a very young age that beyond language barriers, people from different countries/cultures have very different perspectives. Cultural and regional aspects have a very strong impact on the attitude, the mentality, the perspective, and expected behavior in the way people, as well as products, connect with one another.

When I pursued my career, I knew that I was going to do something with cultures and languages. So, localization was a natural fit (a new field when I started…some 20 years ago), and about 10 years ago I pivoted from language support to product geo-fit & global growth.

View i18n Webinar Recording

Lingoport:

So what would you say are the biggest mistakes that you see companies making, and I want to ask you this in two parts. One, companies that are looking to enter global markets for the first time, but then also companies that already have some kind of international footprint. What are the mistakes that each of those types of companies tends to make as they look to expand globally?

Talia Baruch:             

Right. Well, across the board, from startups to multinational corporations, many companies struggle with some common core misconceptions:  

  1. Misconception of one size fits all for global: E.g., US-based companies typically build a prototype, define its value proposition and achieve proof of concept & product market fit for their domestic market. A/B testing and user studies are often done for English US, and then learnings are applied for global markets. The assumption is often that reaching international expansion means having the international customers understand our US-validated product (therefore, translation). While this is baseline tablestakes, the impact component to reach international expansion is, of course, having our product (vision, plan, strategy) understand our international customers within the context of their market ecosystem.

    While most companies invest in language support and build internal localization teams, few companies invest in that second part–integrating the regional and cultural factors in their product strategy roadmap and performance to make their products make sense in their target international new markets. Translation drives some growth (sometimes we even see a 2X growth within the first year of language launch in low-English proficient markets), but this growth rate usually flattens after the first year. Product geo-fit experience and localized product experience, on the other hand, enables sustainable growth in new markets adoption for the long-haul.
  2. Organizational structure: a big challenge many companies have is maintaining efficient open communication between their HQ product teams and their in-country hubs’ functions. This is especially critical for driving international efforts, which are fundamentally horizontal and cross-functional and require constant alignment with the corporate core objectives. Traditionally, companies would have the product HQ in the domestic market (e.g., in the US) and follow a global, centralized management approach in both their technology and team structure–e.g., they’d have a global standard centralized platform infrastructure architecture, as well as HQ-centralized org structure. Today, more companies opt for having regional HQs in their priority target markets–e.g., a Singapore HQ for their Asia markets, MX or BR for their LATAM regions, etc. While the corporate vision and mission should be centralized and consistent, a more flexible structure (modular, decentralized platform infrastructure architecture, as well as org structure), enables them to respond fast enough for local in-country requirements and iterate fast enough on the product front-end to optimize experience in the local target markets.

The positioning of the international team within the org structure is also critical. To effectively build and orchestrate an international expansion strategy roadmap, the international product lead and team need to be positioned as an autonomous unit within product growth org for impact on cross-functional horizontal efforts.

 

View i18n Webinar Recording

New Webinar: The Global Product Strategy Playbook of Leading Brands

There are some remarkable and outspoken leaders in our industry. I admire that they have made Localization shine at leading global technology companies, in the face of some powerful initial resistance.

An Industry Veteran Driving Global Product and New Market Business Growth

On July 25th, Lingoport will be hosting a webinar that brings one such L10n star, Talia Baruch, into the spotlight. I’ll be talking with Talia about a playbook for making better global software, getting input from developers to in-country representatives and users, and creating a more effective global team.

Learn from Leading Brands

Through her career, Talia’s been a force at companies such as SurveyMonkey, LinkedIn, VMware, OpenTable, and Google. Uncover the strategies she used to help these organizations achieve substantial global growth.

Register for Webinar

Building Worldwide Impact

It is among my personal missions to see companies successful in building their worldwide impact. Though as a company, Lingoport focuses on software internationalization, continuous localization and QA systems and services, the most sustaining impact we can enable for our clients is to excel at their global product marketing, and to achieve more substantial local resonance and “stickiness” around the world.  There’s more involved in that than fixing a concatenated string or automating localization for the latest sprint.

Here’s a short list of localization team obstacles I see regularly encountered:

  • Basic lack of understanding around the impact of localization
  • Executive buy-in
  • Developer pushback
  • Sales people wanting more localization
  • Difficulty proving ROI
  • Weak budgets
  • Understaffing

I’ve seen all this get turned around with geo-alignment and teamwork, in spite of some very opinionated egos that needed evidence and persuasion.

Register for Webinar

Geo-Alignment Resources

A few months ago I had a similarly themed webinar conversation with Anna Schlegel, Head of Globalization & Information Engineering at NetApp. I encourage you to view the recordingAnd to read a recent article about geo- alignment from Ms. Schlegel, as well.

I hope you can join us for our live webinar with Talia on July 25th at 9am PT / 12pm ET / 17:00 CET, for your opportunity to learn the global product strategy playbook from a number of leading brands. Registrants will receive a recording and a copy of the presentation following the webinar.

-Adam

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.

The Ultimate Guide to JavaScript i18n

Why It’s Important to Internationalize Your JavaScript

Internationalization (i18n) is the process of preparing software so that it supports local languages and cultural settings. In other words, JavaScript i18n is the process of making your JavaScript application localization-ready. An internationalized product supports the requirements of local markets around the world, functioning more appropriately based on local norms and better meeting in-country user expectations.

Benefits of JavaScript i18n include:

  • Higher quality software that meets the technical and cultural needs of multiple locales
  • Reduced time, cost, and effort for localization (L10n)
  • Single source code for all languages of the product
  • Simpler, easier maintenance for future iterations of the product
  • Greater in-country customer acceptance and satisfaction

The global software market is increasingly growing in demand and volume. Many major software companies derive the majority of their revenue from markets other than the country in which the company was founded. Going global often leads to revenue growth for software organizations.

If you have international users, or if you plan to move into additional international markets, it behooves you to not only internationalize your JavaScript but to also localize your product to deliver both the linguistic and cultural experience that a local user would (and should) expect.

The Risks of Not Internationalizing Your JavaScript

If you choose to skip internationalizing your JavaScript, be prepared for several significantly negative ramifications, including lower sales, weakened competitiveness, and frustrated local users.

It will start when your JavaScript application is confusing to use for a native speaker. When they review and spread the word about the product’s subpar and confusing interface your initial market impression will be poor. Although your audience will want your software’s functionality, they will want and expect an experience tailored to their needs, much as you’ve accounted for in your domestic market.

You may be able to attract early adopters without internationalizing, but for many markets you won’t be able to achieve deeper market penetration. Users will be contacting you and tying up your tech support to understand miscommunicated or simply poorly identified aspects of your program and likely demanding fixes for a number of small internationalization bugs that should have been addressed before the program was released. As word spreads you will have introduced a need for direct competition to your offering in the market.

There’s a better way. Internationalize from the start and satisfy the needs of local users in your global markets.

JavaScript Internationalization Resources

Internationalization & Localization Software

Lingoport Suite is your operating system for exceptional global software, empowering more than 300,000 developers to release software in global markets successfully.

  • Internationalization Software
    With Lingoport Globalyzer, find and fix i18n issues that inhibit localization and global user experience during development. Catch up on i18n technical debt. Avoid rework. Eliminate the manual tracking of locale updates. Collaborate on your i18n efforts via Slack.
  • Localization Process Software
    Make localization proactive using Lingoport Resource Manager. Eliminate error-prone, tedious, manual processes that slow down localization. Detect & manage changes to resource files in your source code. Streamline translation jobs. Automate localization updates between development and translation. Collaborate on your L10n efforts via Slack.
  • Linguistic QA Software
    With Lingoport InContext QA, quickly identify an issue during linguistic QA, enter in a new translation, edit directly on your screen, enter a bug, and have the file automatically updated after approval using your workflows. You’ll be editing directly in the context of your software. No more screenshots!

Questions?

Questions about JavaScript i18n? Contact us for a consultation or to schedule a demo of Lingoport Suite, our i18n software suite.

Top 5 i18n Summer Reading Picks

Perhaps you’re feeling a tad guilty about reading that tawdry novel while on the beach? Here’s some highlighted reading from our globalization archives that will balance things out for you:

i18n Summer Reading 11) The Fastest Growing Global Markets of 2018

Around vacation time everyone likes thinking about travel. There’s no better time to review which of the global markets you should considering entering by the end of this year and see if you can’t make a great argument for a working vacation before the next holiday season.

https://lingoport.com/fastest-growing-global-markets-in-2018/

i18n Summer Reading 22)  2018 Language Services Market Overview

Everyone enjoys a quick read. Common Sense Advisory’s 2018 Language Services Market Overview can be read in just a few minutes. With 10 compelling facts, you’ll feel more knowledgeable about the industry than before you clicked.

https://www.commonsenseadvisory.com/Research/Market_Overview.aspx

i18n Summer Reading 33) The Finnish Language Services Market

Sometimes digging into the details gives the larger picture more context. Nimdzi has done just that by exploring many of the peculiarities of the Finnish market.

https://www.nimdzi.com/finnish-market-2020/

i18n Summer Reading 44) JavaScript Internationalization – the Good, the Bad, and the Ugly Whitepaper

This reading is more technical, providing instruction for i18n within JavaScript. This whitepaper gives a great overview for developers and localization specialists alike.

https://lingoport.com/javascript-whitepaper/

i18n Summer Reading 55) Going Global

We saved the best for last. This book is an absolute must for any business looking at starting or expanding their global presence. Anna Schlegel has written the book you need to read if you want to succeed in an increasingly competitive global economy.

https://www.trulyglobalbusiness.com/about-the-book.html

 

There’s always more on the Lingoport.com blog and resources page.

Happy Summer!

New Webinar: Next Generation In-Context QA

Watch Lingoport’s webinar, Next Generation In-Context QA, and learn about our new InContext QA product, which helps your team eliminate the frustration of linguistic QA for agile global software releases.

View i18n Webinar Recording

Webinar Date/Time

Date: June 26, 2018
Time: 9am Pacific | 12pm Eastern | 17:00 CET
Duration: 30 minutes, plus audience Q&A

Linguistic QA

The de facto practices for linguistic QA are awkward. Linguistic review often happens late or after development, with the reviewers or in-country stakeholders capturing a screenshot, circling an issue and submitting a bug with suggested changes. Fixing bugs often goes unaddressed or is handled late, only after release.

No More Screenshots!

Watch the webinar recording, and learn how, through the use of Lingoport InContext QA, you can quickly identify an issue, enter a new translation, edit directly on your screen, enter a bug, and have the file automatically updated after approval using your workflows. No more screenshots! You’ll be editing directly in the context of your software.

View i18n Webinar Recording

i18n Quick Planning Guide

Internationalization (i18n) is the process of preparing software so that it can support local languages and cultural settings. Let’s say you land a new contract with a company in Japan, or your management team is looking to make an aggressive push into the EU. Then internationalizing your software is the path towards meeting the needs and expectations of local users in those markets.

Software i18n, though, involves many steps and is difficult to achieve efficiently and reliably without the proper step-by-step methodology. The wrong execution can have major ramifications for your development team’s time and your company’s revenue.

To that end, Lingoport has published the i18n Quick Planning Guide to ensure a more successful i18n process. Submit the form below, and receive the guide via email.

Enter Your Information to Download the Planning Guide

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

What Is i18n?

Internationalization (i18n) is the process of preparing software so that it can support local languages and cultural settings. An internationalized product supports the requirements of local markets around the world, functioning more appropriately based on local norms and better meeting in-country user expectations.

Let’s say you land a new contract with a company in Japan, or your management team is looking to make an aggressive push into the EU. Then internationalizing your software is the path towards meeting the needs and expectations of local users in those markets.

I18n is often misrepresented as Localization (L10n) and sometimes even Translation. I18n is product development focused so that in the case of software, one code base is made capable of supporting worldwide languages and locale-specific formatting and behaviors. It’s a critical and sometimes underestimated step that is needed for successful and scalable L10n. Conversely, Localization makes a product specific to a target market or region(s), including translation of the interface and possible adaptation of terminologies and more.

Releasing software that has not been properly internationalized can lead to many problems, including lack of market acceptance. Addressing and fixing i18n bugs after product release results in additional costs, time, resources, and a potentially damaged reputation in local markets. Retrofitting a product for a global market after release, in contrast to internationalizing the source or during development, can be time-consuming, costly, and provide alternative products with a competitive advantage.

What Does Software i18n Involve?

Typical software internationalization tasks include:

  • Developing software to be independent from a specific language or limiting character set, and independent from cultural conventions (e.g., date display, time display)
  • Locale Frameworks
  • Achieving Unicode compliance
  • Elimination of hard-coded text (strings) in the code
  • Removal and reworking of concatenated strings
  • Support for collation of data
  • Support for bi-directional languages, such as Hebrew and Arabic
  • Plus more, including issues that may be application and market specific

Benefits of Internationalizing Software

Benefits of software i18n include:

  • Higher quality software that meets the technical and cultural needs of multiple locales
  • Reduced time, cost, and effort for localization (L10n)
  • Single source code for all languages of the product
  • Simpler, easier maintenance for future iterations of the product
  • Greater in-country customer acceptance and satisfaction

i18n Stories

Companies come to Lingoport with their i18n problems, so we’ve seen a lot that can go wrong with global software releases. Here are some brief examples:

One company had been internationalizing for years, but had persistent i18n bugs that garnered complaints. When counted, there were nearly 500 of them on one product alone. That’s a significant impact, expensive to fix and distracting from new features. By using Lingoport software to support ongoing development, they can now measure and fix i18n issues during development, which is much faster and results in a higher quality global product experience. Using Lingoport’s Globalyzer and Lingoport services assistance, they are working their way through the i18n bugs.

Still another company knew they had an i18n business case, but it was not immediate. They hired summer interns to externalize strings and perform minimal i18n adaptations. Without good direction or appropriate skills allocation, they didn’t get very far. They then sent the i18n offshore to a general contractor, spent over $500,000, and still didn’t have a properly internationalized application. In the meantime, they didn’t feel they were much closer to product readiness, and were passing up new opportunities.

Continuous Internationalization & Localization

Agile development has changed i18n and L10n tasks dramatically, as software changes faster but in smaller increments. It’s easy for i18n and L10n to fall behind. Regarding i18n, it’s often not apparent to a developer that there is an i18n problem in the code they are writing, as the scope of i18n is broad and there are QA challenges. For L10n, there is 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 i18n and L10n with agile teams, rather than hoping to find and fix issues in QA cycles when the development team may have moved on.

The key here is automation. Not necessarily of the actual translation via some machine translation, but managing legacy and new development for i18n 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 i18n and L10n 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 – i18n support in the developer’s IDE, upon check-in and regularly run on targeted source code. 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
  • Integration – Integration with the tools that you are already using, such as a Translation Management Solution (TMS) and Slack for communications

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

Why Continuous i18n and L10n 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.

There’s all kinds of “bookkeeping” issues around managing what’s changed, missing files, getting it out for localization, then putting it back in the source code. By its nature, this delays the process, lends itself to handling errors later when the teams have moved on, shortchanges QA efforts and delays localized releases. It’s costing you time, headcount, and cleanup, and it impacts the global imperatives of your company. Continuous i18n and L10n is simply a much more effective strategy.

i18n Implementation Tips

For legacy i18n refactoring and new development:

1. Learn, Build and Support the Business Case
Continuous i18n and localization (l10n) in support of agile development is going to have a cost. Unless the business case is defined, the project is unlikely to get done. Make sure you build a strong business case to compel all team members to align on i18n implementation.

2. Clarify Your Global Release Objectives and Concurrent Development
i18n touches a good deal if not all of your application, rather than being like adding a feature or fixing a bug in a particular sprint and area of your code. It usually involves more than your software’s presentation layer, as data is input, stored, transformed and retrieved. When internationalizing your product for the first time, you’ll need a branching, merging and testing strategy that covers the full i18n scope.

3. Assess and Document Requirements
Establish user requirements as they relate to target locales. i18n is almost never just a string externalization exercise you can pass to an intern. You’re going to need to put some thought into locale requirements, how data is going to flow through your application, changes to your database, methods/functions/classes that will have to be made locale-aware and of course the U/I and all it’s strings.

4. Build a Plan
An i18n project plan typically starts with about 200 tasks and increases with size and complexity (consider this for multi-tiered applications). To build this type of plan, one option is to analyze the code base with Lingoport’s i18n software product, Globalyzer, which provides detailed static analysis on internationalization issues that will need to be addressed. Combine that with architectural analysis from whiteboard discussions and requirements documentation.

5. Reduce Risks and Manage Trade-offs
Being late in deploying your global software is very costly to your business. The risk can be a broken agreement, market launch and business plan. A three-month delay may make an annual revenue goal unattainable. Ensure that your executive management team is fully bought in to your i18n efforts, and that your team has the budget, resources and tools to get the job done efficiently, reliably and successfully.

Internationalizing a large application is generally resource intensive. In cases where you have lots of legacy code, you may need an implementation partner in order to keep up with ongoing development objectives outside of internationalization.

6. Long Term Support
Once you internationalize and localize your software, your ongoing development has a new set of requirements. Measure i18n just like any other coding quality. Do not wait until testing to find out if i18n is broken. For your ongoing agile development, it’s good to automate the management of changes to strings that may change somewhat with every release.

Common Mistakes Made When Trying to Internationalize

Be sure to avoid these 10 common i18n process mistakes:

1. Don’t Forget What Drives Internationalization
Your company’s top and bottom lines. The costs of being late or delivering lousy quality products endure beyond any benefits of cutting corners on development.

2. Don’t Assume Internationalization Is Just an Older Software Legacy Issue
No framework, whether it’s React.JS, J2EE, .Net, Java, Ruby on Rails, PHP or whatever is new and improved, internationalizes itself. You still need to perform all the steps necessary to implement locale and all the associated i18n practices.

3. Don’t Assume You Can Treat Internationalization Like Any Other Feature Improvement When It Comes to Source Control Management
It’s typical for new feature development and bug fixing to be conducted in parallel with i18n. However, in the process of performing i18n, 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 i18n 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.

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.

6. Don’t Create Your Very Own Internationalization Framework
Various companies have half-way implemented internationalization using their own homegrown methods for string extraction and locale management when there were already well established methods provided within their programming language framework or established solutions like ICU. Using these methods or solutions will ensure that your code is far easier to maintain. No unpleasant surprises.

7. Don’t Think That the Team Internationalizing Your Software Can Work without a Working Build
Without a working build, the developers can’t smoke test the changes they are making. Even if you provide a dedicated QA person, 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. It’s odd that we even have to mention this, but it comes up.

8. Don’t Run Out of Money
I18n planning often suffers from underscoping. Lapses in funding can cause expensive delays, as new funding takes more time than anyone imagined to get approved. 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.

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
Use pseudo-localization of not only the interface, but send 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. In your pseudo-localization testing, expand data fields to fit physically longer strings, accounting for expanded strings from translation. Pseudo-localization is automated when you use Lingoport’s Resource Manager.

State of the i18n Industry

Lingoport recently conducted The State of Continuous Internationalization & Localization Survey. There’s been plenty of talk within our industry about making i18n and L10n continuous, automated and in step with Agile development. However, we wanted to uncover the true state of the industry and therefore launched the survey.

The reality is, the industry still has a long way to go… For example, only 8% of respondents thought they did an excellent job at measuring and managing i18n requirements. Download the report to see where the industry stands on localizing for every sprint, the lag time between feature releases and L10n turnaround, and other global software development issues.

Download the survey results.

Lingoport’s Market-Leading i18n Software & Services

Lingoport is the premier i18n software and services company in the market. If you are looking for software, or for i18n assessment, consulting or implementation services, we encourage you to explore the following links and to contact us at any time.

  • Lingoport Globalyzer – Find and fix i18n bugs. Lingoport Globalyzer is your operating system for exceptional global software. Avoid rework. Find and fix i18n issues as the code is written. Default rules and machine learning pinpoint existing i18n issues in source code for a wide variety of programming languages and database scripts. Improve your agile software development for global markets with Lingoport’s flagship i18n software.
  • Lingoport Resource Manager – Automate change detection and export/import resource files for localization with Lingoport’s localization process management software. Eliminate error-prone, manual processes and save thousands of hours of engineering time.
  • Lingoport Dashboard – The hub of our i18n suite. See it all, drill down, create notifications and manage the process. Bridge gaps between localization & development. Increase visibility and track globalization metrics.
  • Lingoport i18n Services – Benefit from our 17 years of experience. Enjoy expert teams for software i18n assessment, planning and implementation.

Lingoport Webinar: Highly Effective i18n Planning

JavaScript Internationalization – the Good, the Bad, and the Ugly Whitepaper

There are many standard practices to follow when implementing proper internationalization (i18n). For those looking to understand the details of proper i18n when coding in JavaScript we’ve put together this white offering.

Download “JavaScript i18n-the Good, the Bad, and the Ugly” whitepaper, which will allow you to leverage the expertise of Lingoport’s experts to improve your i18n JavaScript.

Submit the form below, and the whitepaper will be emailed to you.

Current Locale Resulting Block | Internationalize JavaScript

Enter Your Information to Download the Whitepaper

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

Feature Release: Lingobot IDE – make the i18n workflow even more efficient

For those looking to get through their i18n (internationalization) workflow in less time, we are introducing a new feature. Lingobot will now be accessible within development’s IDEs (Integrated Development Environment) such as Eclipse, IntelliJ, or Microsoft Visual Studio. Meaning users can now push i18n commands, check on L10n (localization) status and more directly within their development environment.

New Face for Lingobot

This new access point is a direct extension of Lingobot, which means developers have direct access to push commands through the Lingoport Suite without leaving their work environment. Lingobot has previously been available through collaborative tools such as Slack or Flowdock. Either method allows the team to leverage the power and benefit of Lingobot, at whichever point is most convenient, keeping them focused on the task at hand.

Project List

Dropdown

Lingobot functionality can be accessed via prompts with a command line which is a direct but unintuitive approach. This new access reaches beyond and can integrate a dropdown menu for i18n commands directly within the IDE. Meaning strings can be pushed for translation with a couple of clicks. This also means developers don’t need to reference a syntax guide any time they want to push an i18n command. The drop-down menu is easier to use and far more accessible.

Developers are now able to check for critical errors, pseudo-localize, view their projects, or even view the status of translations in a specific branch of their program without ever clicking away from their code.

Lingobot Menu Options

Reporting

Lingobot will also track the status of translations in real time. This means even to check on the progress of a project developers won’t need to leave IDE. This also allows users to react more quickly. If users are waiting for the translation to come back before taking the next step in a project they can keep an eye on the progress in their work environment. This helps cement coordination with the localization effort, by not needing to click between applications. 

Lingobot Translation Status

Now anyone needing to access the power of Lingobot can do so directly through the Lingoport Suite, via their collaborative tool, or even directly in their IDE.

This new IDE access is but one feature to make i18n work for your company while your team spends less time working on i18n.

If you’d like to learn more about this or other features please contact us.