New Webinar: Highly Effective i18n Planning

Watch Lingoport’s webinar, Highly Effective i18n Planning. During the webinar, we advise you on a step-by-step planning methodology for achieving a reliable software internationalization (i18n) process.

View i18n Planning Webinar Recording

Webinar Date/Time:

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

Step-By-Step i18n Planning

There are many ways that i18n efforts can go wayward, costing you time, resources, and revenue. During the webinar, we outline the specific planning steps required for more reliable software i18n success. The steps are essential knowledge for anyone involved in software i18n, including localization professionals, product and program managers, scrum masters, product owners, development managers, and senior engineers.

I18n Planning Guide

Complementary to the webinar, download Lingoport’s i18n Quick Planning Guide. With both the webinar and the guide, you’ll learn what it takes to achieve a smooth, efficient, and effective i18n process.

View i18n Planning Webinar Recording

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.

New Webinar: Pinpointing i18n Issues Quickly with Machine Learning

We invite you to watch a recording of Lingoport’s recent webinar, “Pinpointing i18n Issues Quickly with Machine Learning.” Machine learning is quickly changing the software development and testing landscape. View the recording, and learn to put machine learning to work so that your teams create better internationalized software, faster, easier and more naturally in every sprint.

Date/Time

Date: Wednesday, April 25, 2018
Time: 9am PDT, Noon EDT, 18:00 CEST
Duration: 45 minutes plus Q&A

Internationalization (i18n) Prevents Localization Problems

The best way to deal with i18n issues is to find them as the code is written or committed to source. Now, we have a predictive method to make this type of detection faster and easier than ever before.

Lingoport Globalyzer Now Powered by Machine Learning

The most common objection to i18n detection during development involves dealing with false positives. It takes a sophisticated detection system to distinguish between a true i18n issue and a programming element that looks like a problem but isn’t.

Lingoport’s Globalyzer has had multiple methods to do this by default and through customization for years, but through the implementation of machine learning, we’ve taken a further leap forward for powerful i18n detection even for highly unique software requirements.

What You Will Learn

  • How to bridge gaps between L10n and development
  • Effective i18n issue detection in source code
  • The false positive conundrum
  • Applying machine learning to i18n issue detection
  • Scaling i18n expertise across your development teams
  • Measuring, collaborating and supporting i18n in every sprint

Who Should Attend

  • Localization Managers
  • Development managers
  • Localization and development engineers
  • Product, Program and Project Managers with international objectives

View i18n Webinar Recording

New Webinar: Turning Agile Localization from a Cost into an Investment

We invite you to watch Lingoport’s webinar “Turning Agile Localization from a Cost into an Investment,” exploring some of the negative attitudes related to agile internationalization and localization in the software industry, and how to transform executive management’s thinking into a more positive, proactive, and investment-oriented mindset.

Date/Time

Date: March 28, 2018
Time: 9am PT; 12pm ET; 17:00 CET
Duration: 30 minutes, including audience Q&A

The Biggest i18n & L10n Challenges

Lingoport recently conducted The State of Continuous Internationalization & Localization Survey to uncover the state of the industry as it relates to agile software development. In the survey, each participant highlighted their respective company’s number one i18n or L10n challenge. This webinar will examine the most common answers to this survey question, and will explore solutions representing a win-win-win for development, localization, and product management.

Lack of Buy-in. Lack of Support.

There were two leading issues reported among the survey responses. The first was a lack of management buy-in with regards to the importance of internationalization and localization. The second was insufficient support for Agile localization. From where we sit at Lingoport, buy-in and agile support are intertwined in terms of how solutions are implemented and the effect on workflow and development.

Agile Localization as a Strategic Investment

Watch the webinar recording and see what it takes to change minds and make agile localization a key part of your organization’s global software development process. Learn common mistakes by upper management, and discover lost opportunities to introduce agile localization as a standard within your development process.

Who Should Attend

  • Localization Managers and Engineers
  • Marketing Managers
  • Development Managers and Team Members
  • Product and Program Managers
  • Executives

Webinar Recording

VIEW THE RECORDING

 


The State of Continuous i18n & L10n Survey Results

Phasing Software i18n and L10n: What’s Right for Your Company?

Going global is a big step. Moving from the massive challenge of getting a company off the ground and past the initial challenge of proving that your idea can work has already put your company in a league beyond most.

Aside from incidental web traffic and interest from new countries and regions, for many companies, going global means setting up partnerships, offices and agents. For software, it also means internationalizing and localizing software so that it’s competitive and meets sales requirements. Internationalization (i18n) of your software is a business case driven undertaking, in response to opportunities and strategy. It is not like a feature that you might add in a sprint or two.

That said, all global targets are not equal in terms of technical requirements. This post gives you a brief overview of stages of software i18n and localization (L10n) and what opportunities each may open for your company. It’s not intended as a technical resource, but more as a primer for product and localization managers.

The Basics

Venice, Italy

  • Internationalization, often abbreviated as i18n (i – then 18 letters – n), is the process of making a single code base locale-independent so the application can be easily localized to other locales with no source code changes.
  • Localization, often abbreviated as L10n (L– then 10 letters– n), is the translation and application of locale-specific terms and style so that a product is locale-specific – that is, it looks and reads like a product native to the market in which it is being sold.
  • Globalization, sometimes abbreviated as g11n (g– then 11 letters– n), includes both internationalization and localization together and often refers to the entire process of supporting other locales.
  • A locale in computing is a set of parameters that defines the user’s language, region and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier. Consider that in both the US and the UK, the typical language is English, but other parameters such as date format, temperature and even some spelling is different.

Why Wasn’t It Internationalized in the First Place?

Venice, Italy

In a perfect world, all products would be created with i18n as a fundamental requirement from the start. But often with new product development, teams are just trying to make a product work and see if there’s a response. The initial focus is on relevance and acceptance of the application. Follow-on efforts are feature focused. I18n isn’t really like a feature, as its requirements underpin an entire application.

As mentioned above, going back and internationalizing code requires a business case. It takes time and will distract the development team from new features. There are times when products are rewritten, which is an excellent window to spend some effort on internationalization. In many cases i18n is a good opportunity for outsourcing, bringing in i18n expertise that allows your team to focus elsewhere, while still learning from the experts to ensure that future development will be internationalized. Expert help enables you to implement i18n faster with greater quality and less project risk.

Although people often think i18n is just about string externalization and the resulting localization, there is much more involved. There are locale frameworks that will govern locale behavior, methods/functions/classes that may need to be changed, static files to alter, and even hard coded patterns (e.g. a hard coded font) that may need fixing. Issues like date/time, address, phone number, numerical and measurement formats will have to adapt to local preferences. You’ll need character support, sorting changes and more. String externalization is like the visible part of an iceberg. You see it, but there’s much more below the surface.

Consumer Facing Software

Vernazza, Italy

It’s easy to see how consumer facing software has a higher requirement for i18n and L10n if it’s to gain broad acceptance, even in markets where English is more common.

That said, we do hear the argument that English is commonly used and understood in many places. Remember, if you travel to major cities in Europe, you’ll find that you can get along with English pretty well. But in terms of product preferences, people typically prefer engaging in their own languages. As you get out of major cities, you’ll find less English proficiency. Even with English (which English?) you still have formatting issues as mentioned, like decimal and comma placement in numbers.

Technical Software

Internationalization Phases

We see the “English everywhere” argument even more with technical software. To an extent, if your users are technical (i.e., system administrators), you can use English in more markets. But you’ll fall flat in Asia Pacific countries, such as Japan, Korea and China.

Below is a broad summary of i18n phases or levels which can be applied depending upon the business case. The best is to be global ready for everywhere of course.

Unicode

If your targets are in Western European languages (i.e. French, Italian, German, Spanish, Portuguese and more), you won’t need Unicode support in your application. That said, if you’re working on i18n, I like to recommend that people take on Unicode as early as possible. Most every modern database and programming language offers Unicode support, but you have to enable it. In our experience, Unicode support can be about 25% more work on an i18n implementation (there are exceptions), but remember that if you’re already in the code making i18n changes, it’s more efficient to do it now than restart the process later. This is a generalization, and there are plenty of specific application, business case and market driven exceptions. For example, somebody sold something and you have to deliver your product in Brazilian Portuguese in three months (true story!).

Unicode support will need to be a prerequisite if you have plans for markets/languages with complex scripts such as Japanese, Simplified and Traditional Chinese, Korean, Vietnamese, Hebrew, Arabic and Cyrillic based languages (i.e., Russian).

I18n Phase 1: Data

Internationalization

The very first internationalization priority should be the ability to input, process and transform customer data. In my opinion, this should be a benchmark requirement for any software that could have global customers or enterprise customers, whether or not localization is considered to be in the future. Note that the U/I is not changing in this phase. There is no U/I localization yet.

Even if you are actively selling only in your home country, it’s likely that you will run into customers in other countries, or your customers will have customers in other countries. At least let people enter data in multiple languages and formats. Store it, transform it and retrieve it without corrupting it.

Minimally, accents and diacritics shouldn’t cause character corruption (those square boxes and odd shapes you’ve probably seen). Better yet, add unicode support in the database and source code.  Character corruption shouldn’t be caused via issues in the various components of your product source code.

Character corruption example:

Character Corruption Example

Better if data can be stored and managed in variable formats for information such as date/time, numerical units, addresses, phone numbers and currencies.

Automation is the best approach to achieving this in a seamless, efficient and scalable manner. To that end, Lingoport’s Globalyzer can be used to scan your source code and database scripts to find these issues and guide developers to fix them. Our services team can perform refactoring work, as well.

I18n Phase 1.5: Locale Frameworks

You’ll need a locale framework for each programming language within your source code.

This paves the way for string externalization and presentation which will be needed for localization. Presentation of formats for date/time, numerical units, addresses, phone numbers, collation, currencies and more are also controlled by locale frameworks.

Lingoport’s services teams can help you make the right choices and even implement them for you.

I18n Phase 2: Language and Localization

Italy

String externalization is often what most people think of as the critical i18n and L10n step. User-facing words or strings are removed from being embedded in the source code and replaced with a function call typically to a resource file where the strings will now reside. This way, if the user selects a locale preference (remember those locale frameworks), French in France for example, the code will retrieve the French strings in the resource file for presentation.

String externalization can be tedious and time consuming. The issue is that lots of things may look like strings at the source code level that aren’t actually user-facing strings. Examples are named variables, debug statements and internal queries. Lingoport’s Globalyzer has default and extendable capabilities to aid these distinctions. Globalyzer Workbench enables an i18n engineer to assemble strings, walk through them and then externalize them in bulk.

You’ll also want to test your work. Lingoport’s Resource Manager will automatically generate a pseudo-locale that will help your team functionally test how the software will behave in another language, without the testers needing to understand that target language. Pad characters are added around the original English strings with expansion automatically set based on typical U/I requirements in the target languages. Alternatively, the expansion can be configured manually. This way, testers can immediately see any missed strings or U/I elements that won’t properly expand for likely longer words and changes in fonts in other languages (i.e., German, Chinese).

Pseudo localized page for a family tree application:

Pseudo-localization

I18n Phase 2.5: Workflow

With some software, workflow and processes are different depending on market requirements. This takes market research and coordination with in-country representation. For instance, tax management, or medical administrative software is likely to have different requirements and steps in most markets.

I18n Phase 3: Bidi Support

i18n Phases

If your product is being sold in places using bi-directional languages such as Hebrew or Arabic, you’ll need to enable and test your pages to support U/I mirroring and the bi-directional nature of text that goes right to left, but with left to right elements within. Unicode support is a prerequisite.

Ongoing i18n and L10n

Fight Mojibake!Now that you’ve internationalized and localized your software, your work isn’t over. Your teams will be steadily releasing new features and functionality. I18n surprises can arise down the line that cost time and iterations to fix. It’s not hard for a developer to make a mistake. Just as your teams may continuously measure for coding quality issues and security, i18n quality now becomes another metric.

Localization for every sprint, branch and repository makes for tedious and error prone work that slows agile progress. That process can be automated, taking your developers out of the resource file update nanny business.

Lingoport Suite’s Globalyzer continuously supports i18n from the developer IDE to source repositories. Lingoport’s Resource Manager automates resource file updates from source to translation and back again, with quality checks in each direction. QA is supported as well.

Lingoport Dashboard lets teams see and manage i18n & L10n status and process, supporting i18n issue drill downs to associated source code, issue assignment and completion. Similarly, Localization resource file issues can be itemized and examined.

We’ve seen teams go from 5-week localization update cycles to under 3-days over hundreds of repositories. Our services teams have internationalized many well known applications ranging from small to millions of lines of code, and you would be surprised to see the efficiency gains that are achievable in the development process.

We hope that you find this primer useful as you look to address i18n and L10n of your own software products. If you have any questions, do not hesitate to reach out and a Lingoport team member will be happy to talk through the issues with you.

Other resources:


The State of Continuous i18n & L10n Survey Results

The State of Continuous Internationalization & Localization Survey Results

Lingoport recently conducted The State of Continuous Internationalization & Localization Survey, and the results are in!

There’s been plenty of talk within our industry about making Internationalization (i18n) and Localization (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…

Enter Your Information to Access the Survey Results

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

A Serious Lack of Internationalization Measurement & Management in the Software Industry

Lingoport recently conducted a survey titled The State of Continuous Internationalization & Localization. Through the process, we received 121 responses from members of the industry.

State of the Industry Webinar

We highlighted the results of the survey during our webinar, The State of the Internationalization and Localization Industry, on February 28, 2018, and I invite you to watch the recording of the webinar here. (The webinar also features an interview with industry leader Renato Beninatto of Nimdzi Insights for his additional insights and perspectives on the survey results.)

Internationalization Measurement & Management

One thing that especially caught my eye with the survey is the lack of a documented and formalized process, with metrics, for measuring and managing internationalization (i18n) at the majority of companies.

Only 8% of respondents thought they did an excellent job at measuring and managing i18n requirements. Just over forty percent (40.5%) have either absolutely no process or reported that they barely had a system in place. This represents a major opportunity for companies to upgrade their i18n management infrastructure, which would improve software quality and reliability.

Some form of software quality measurement is a basic benchmark for any desired software requirement. To be weak on measurement is to rely on randomness, which is never a good idea.

If your company falls into the category of lacking an i18n requirements measurement & management system, perhaps you now have a new agenda item to raise at your next team meeting.

Watch the webinar recording.

-Adam


The State of Continuous i18n & L10n Survey Results

Apple’s i18n Bug Makes the News

Apple’s iOS Character Bug and Internationalization (i18n)

It’s rare that an i18n issue makes the news. In fact, in a meeting a few years ago with an i18n and localization team, one member lamented just that. “Nobody gets fired for a character corruption issue. That just doesn’t make the news.” The context was that security issues get the attention and with that gobs of budget. There is nothing like the fear of a breach, lawsuits and public humiliation coming with an i18n or localization (L10n) shortcoming. However the problems can still be insidious.

Let’s look at Apple’s iOS bug. It actually did make news, but could have easily been missed in this week’s tumultuous news cycle.

As reported: When a user inserts a particular character from the Telugu language (India) on iOS or MacOS, the system crashes hard. This can even take place from within applications running on those systems. The character looks like this:

Apple Bug

i18n and L10n Matter

Going back to our security bug comparison, let’s consider carrots and sticks. Security is a stick. Don’t handle it right and you get beaten. But if you perform i18n and L10n well, and you have a good product, you’re going to see a different kind of reward. This is absolutely no different than the benefits of paying attention to usability in your user interface. Software that works and behaves elegantly, has a competitive advantage with applications that may not. So it is for products that work well in any language and locale preference. Yes, there are some markets that are more US English tolerant, but they will still need all kinds of other locale formatting for a multitude of data like dates, numbers and addresses.

Want to grow? Go where the people are. Look at Facebook, with 87% of its users outside North America (including US, Mexico and Canada). Netflix has been growing consistently based on expanding their presence worldwide. Even consider technical products, whose managers perhaps had the excuse that system administrators have to learn English anyway. Have a listen to our webinar recording with Anna Schlegel, who leads Globalization efforts at NetApp. They place great strategic importance to their i18n and L10n efforts as a critical product strategy, and not just a checkmark.

If It’s So Important, Why Is It Hard?

There are many reasons why both i18n and L10n can be challenging. Developer teams are tasked with steadily implementing new features and fixes. I18n requirements are often not fully understood. You have organizational turnover, far flung teams, disparate understanding of i18n, and the fact that perfectly functional development may deliver the feature, but not the locale requirement. Testing may or may not ever directly relate to i18n and L10n within the same sprint. Then figure that you have multiple sprints and often source control branches being fired off concurrently. Even more experienced companies with their own internal technology investments tend to have a jury-rigged series of scripts that still depend on human action and are subject to process error and delay.

This is where our Lingoport Suite software for managing i18n and L10n can make for significant gains in quality, time to market and development savings. It is natural that if you find i18n issues during the day’s development tasks, you can fix them easily and quickly without any backlog or impact on your development velocity. Same goes for localization changes. Automate those, and you can stay right on target and never have to search for changes and updates to files. If one little string changes, it’s no big deal. The updated translation is automated out and back into your code. Plus it’s all made visual via dashboard and controllable even through collaboration tools like Slack. Even the QA team has continuously updated test cases, so that US English (or whatever your home language may be) is just another locale.

Back to the Apple Bug

I did a little reading plus reached out to a few experts beyond our team, to pin down what might have happened at Apple. Their situation is probably not a simple case of using some deprecated function or locale unsafe class. Apple does support Unicode after all. It’s a bit surprising that one Unicode character out of some 55,000 in the first Unicode plane would cause such problems. As a (useless) guess, something is going wrong at the OS level when the character is processed and displayed. Perhaps the character processing algorithm, in this case, leads to a buffer overflow. Even if you don’t expect to converse in Telugu, nefarious types are using the character in text bombs to disable Apple devices. A fix is forthcoming.

Why This Matters:

It’s unlikely that you’ll run into a bug this complex within typical application development. But this is an excellent illustration that it’s far less painful to get i18n and L10n right before release. Have good systems for finding and fixing issues like embedded strings, concatenations, functions/classes that aren’t locale safe, character encoding bottlenecks, and programming patterns that mess up your intended results. Then take out the file nanny busy work around localization updates so every sprint is easily localized. Win over your worldwide customers with software that’s up to date with their own preferred locale behavior and language.

Further reading:

Bug report: http://www.openradar.me/37458268

Interesting analysis: https://manishearth.github.io/blog/2018/02/15/picking-apart-the-crashing-ios-string/


The State of Continuous i18n & L10n Survey Results

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

New Webinar: 10 Questions with Industry Leader Renato Beninatto

Renato Beninatto

I invite you to watch our webinar, “The State of the Internationalization & Localization Industry,” in which I interview Renato Beninatto, industry leader and CEO of the market research and consulting firm, Nimdzi Insights.

Renato has served on executive teams for some of the industry’s most prominent companies and is the author of the book The General Theory of the Translation Company. Renato was the president and is currently an advisor to Elia (European Language Industry Association) and is also an ambassador of Translators without Borders.

Plus, I’ve known Renato for, well…, forever, and assure you that he’s always full of incredible insights and energy. The webinar is not only educational, but also quite entertaining.

The State of the Industry, Revealed

Renato Beninatto, NimdziDuring the webinar, we explore the current state of the internationalization and localization industry with Renato. We look at where the future is taking us and how you can position yourself as a key globalization influencer in your organization. In addition, I walk through 10 questions with Beninatto, exploring the biggest opportunities in localization today, the ideal role of globalization vendors, the future of globalization technology, and more.

Plus, as an added bonus, we round out the discussion by revealing insights from Lingoport’s recent The State of Continuous Internationalization & Localization Survey. Cut through all the hype and discover where the industry truly stands today.

What You Will Learn

  • The leading localization opportunities in the market today
  • Effective approaches to leading globalization at a growing enterprise
  • The ideal role of globalization vendor partners
  • How to use technology to connect developers, marketing teams, localization teams, in-country offices and vendors in Globalization teamwork
  • What’s next for technology in support of global releases
  • Results from Lingoport’s State of Continuous Internationalization & Localization Survey

Who Should Attend

  • Localization Managers and Engineers
  • Marketing Managers
  • Development Managers and Team Members
  • Product and Program Managers
  • Executives

Hope you are able to watch the webinar recording and to enjoy the insights.

– Adam


State of the Internationalization & Localization Industry Webinar