Our mission is to empower technology companies to create products that work elegantly in any language and cultural requirement, by making software internationalization (i18n), i18n testing and localization a straightforward and integrated aspect of software development for every team and sprint. I’m proud and appreciative of our development team given the extent of functionality in this suite release that moves us all on that mission.

Underlying themes for our entire Lingoport Suite Release include:

Collaboration – Integration with collaboration platforms like Slack and Flowdoc

The release also marks the introduction of LingoBot, who you can query for up-to-the-moment i18n and L10n status via collaboration platforms such as Slack and Flowdock.

There are many new features and benefits, which I’ve summarized here including links to release notes:

LingoBot and Collaboration: With collaboration tools like Slack becoming a predominant communication venue for many development organizations and teams, we wanted to bring i18n and L10n status queries into the conversation. You can ask Lingobot questions about the status of a branch and more and receive Globalyzer and LRM updates as well as initiate actions. You can also issue commands such as pseudo-translate a particular branch for testing, or send out updated resource bundles for translation.

Security concerns dominate most IT organizations. Although use of Globalyzer has never required visibility of source code to the Globlayzer server, we now enable customers to download and locally manage rule sets that previously were hosted on the Globalyzer Server. These rules add accuracy and customization to Globalyzer issue detection. Moving them to a local disk keeps Globalyzer Lite operations completely within the customer’s network. Globalyzer Lite integrates with developer IDEs and can automate i18n against pull requests, specific files or entire repositories. That also adds a speed benefit as there’s no delay to a Globalyzer Server when first connecting.

Additionally, there were several other security upgrades, as detailed in the release notes.

Accuracy: In nearly every release we look to find ways to improve Globalyzer’s i18n issue detection. In this release, we’ve taken on flagging false positive detections in a quick way for individual issues and when you don’t want to take the time to write a filter. From the Globalyzer Workbench, you can quickly review and sort detections in context of your source code, and flag one or bunches of them as false positives and share that with the dashboard so that the entire team has the same view of issues.

Ease of Deployment: As teams expand more products and repositories for Globalyzer Lite and LRM for continuous i18n & L10n, we’ve made onboarding much faster with our Jenkins plug-in integration.

Lingoport is pleased to announce a series of new features in Lingoport Suite, the market’s leading solution for software internationalization and localization management, with billions of lines of code scanned. The new features improve a development team’s ability to seamlessly and efficiently launch agile software for international markets.

With Lingoport Suite, your software development team can eliminate chaos, avert rework, and launch exceptional global software with greater visibility, reliability, and scalability. The new features focus on areas of collaboration, continuous integration, and security. And you can learn all about them in our webinar from August 22, 2017 — the webinar recording is available here.

What’s New

Better Collaboration: The past few years have brought about an explosion of collaboration platforms such as Slack, helping to connect teams more effectively than ever before. To help your software development become a well-oiled collaboration engine, Lingoport Suite messaging is now integrated in these new collaborative tools.

Even cooler, we’re introducing everyone to a new friend, Lingobot. Teams can query and command Lingobot for status and functions, even using natural language.

Continuous Integration: High-performance software teams now depend on dynamic agile development, with simple and fast deployment and processing. In response, we’ve introduced new features that accelerate the onboarding of new projects.

Enhanced Security: In addition, the need for security is always intensifying, and with that in mind, we’ve made a number of security enhancements to satisfy the security needs of startups to enterprises.

Webinar

We’ll change the way you think about building global software.

Please note that the webinar took place on August 22, 2017, but you can view the recording here. Be sure to check back soon, and learn how our latest innovations will help your software organization to up its internationalization and localization game.

Building a Better Software Globalization Process

Want to shatter the black box of obscurity, and instead increase enterprise-wide visibility of internationalization and localization issues during software development?

Want to reduce time spent putting out fires related to post-release international versions of your software?

Want to reduce unnecessary (yet all-too-common) costs?

If you answered “Yes” to any of these, then this webinar is for you. Join us on July 26th and up your software globalization game by learning how to 10X your productivity for seamless international software releases.

10X Productivity Across 44 Languages

In this webinar, Lingoport will interview Rob Thomas, Senior Project Manager for FamilySearch, and as we hear about his 10X gains in productivity and reliability in releasing applications in up to 44 languages. FamilySearch is a large site for genealogical research provided by the Church of Latter Day Saints. There are over 400 team members responsible for its development, testing, and release. Like many SaaS applications, the FamilySearch site is continuously updated.

The localization industry has been late to the party regarding continuous integration (CI) of its services with software development. Continuous Globalization is finally getting the attention it deserves now, and that’s a good thing not only for the software industry but also for end users around the world. Here’s what continuous integration, and more specifically continuous internationalization (i18n) and localization (L10n) are, and what it can mean for your software development process.

The Basics of Continuous Globalization

For the uninitiated, Wikipedia defines software continuous integration, or CI, as the practice of merging all developer working copies to a shared source repository several times a day. Multiple builds and automated tests and quality profiles are run against the code to identify bugs and other issues quickly. The sooner you find those issues, the less costly in time, effort, and money they are to fix. CI is fundamentally supportive of agile development principles. Automated quality profiles can include coding quality measurements, security, and more.

Lingoport has been working with some of the largest, well known global technology brands with its continuous internationalization suite of software, Lingoport Suite, including internationalization support for developers, QA support, and localization streamlining. These products work seamlessly with agile-friendly localization providers, providing software companies with systems and services to back up their fast moving product development efforts.

Beware the Invisible Costs

Happily, we don’t usually have to extol the benefits of CI to development teams. I’ll also note that internationalization (i18n) and localization (L10n) requirements are far more openly received than years ago.

That said, managers will comparison shop to lower localization costs per word but can inexplicably regard engineering costs involved in chasing i18n bugs, accounting for localization file updates, and iterative testing as invisible. That typical process involves manual, error-risk prone work even if there are scripts involved. If anything goes wrong with file formatting or myriad other nits, the time to trace it back and fix it eclipses a few penny savings here and there, and can be downright costly in financial terms and damaging from a brand perspective when viewed holistically.

For example, if you consider a SaaS application, perhaps with 5 to 15+ simultaneous sprints running at any given time and with three to five developers per sprint team, there is a lot of room for i18n issues to arise. The localization for any particular sprint or release might be quite small. For example: a few words added in one menu, a new error message, and some new functionality that add up to five to 10 new files with an average of 34 words needing localization per file. The minute someone has to manually handle any of that, you’re losing money and momentum. It costs far less in money and time if i18n issues are found right during day-to-day development, and the localization flow from repository to translator and back to the repository is managed automatically, including validation checks.

Dealing with Short, Fast Development Cycles

If your teams are agile (most teams are at least using some form of agile methodology now), it is particularly challenging to include both internationalization and localization processes within a two to three week or shorter cycle. However, we’ve seen clients using systems go from 5 week localization turnarounds, to three days. Consider that if your i18n and L10n are not integrated and automated within your sprints, you are defacto pushing them into the backlog. As your developers move on to successive sprints, if there is a problem with i18n and L10n that needs development and QA attention, they have to stop what they are doing, figure out what the problems are, where they are located, and fix them, and then QA must again verify that fix. That costs time, money, and momentum. It also likely means that your globalized users have to wait for new releases.

Keep in mind that many software development projects are moving to micro services architectures, which break repositories into many little components that get mixed and matched based on product configurations. This makes the business case for continuous i18n and L10n even more pronounced.

Human Factor Issues

A very common developer practice is to concatenate a string or message to the user. The message builds based on elements such as variables, plurals, and conditions that determine what the software needs to convey. This is how developers are taught to write code. It’s very efficient if there’s only one language involved. Even if that concatenated string is properly externalized, the word order is likely to be completely different in another language, making the translated version at best quaint, and at worst nonsensical. Since the translator doesn’t see the whole string together, they can’t produce a quality translation. However, if concatenations are found right in that day’s work for the developer, correction is quick and painless. Wait until testing, and now we have a multi-step process.

Another example is a developer not using a proper class or method that can support locale, or not passing locale to a class. Perhaps they are using a calendar class, such as SimpleDateFormat (Java). This will render a US formatted date just fine and will pass unit tests, but it’s not going to go well on a system with a different locale date formatting preference.

If you catch these sorts of issues as the developer is writing or committing their day’s work, it’s minutes to fix them. Find them later, and likely QA has gotten involved, the developer has to track down the issue (often not obvious to locate in the code), verify it’s fixed and then update a bug report. It’s no wonder these issues slip in favor of a release date.

Automation, Efficiency, and Speed

For QA, a pseudo-locale is created automatically which adds pad characters around strings so that the tester can see the U/I in English. The pad characters prove that the interface can expand to support likely longer translated dialogs and more complex character sets. Again, nobody has to remember to run a script at some point in time. The updates are automatic and continuous. When the interface is changed by the developer, the pseudo-locale update is automatically updated. This gives QA departments immediate functional U/I test cases for every new feature that confirms to worldwide requirements.

For localization, the changed U/I resource files are automatically detected. Those files are then automatically vetted for quality checks (i.e., no duplicate string IDs, proper file formatting, and more) and sent out for translation or pushed into a Translation Management System (TMS). The localization vendor, which must understand and even thrive in agile localization, then delivers the translations, which are updated leveraging a TMS, Localization Vendor Portal or other translation systems, and our Resource Manager process verifies the file formatting again and takes care of updating the source repository.

Nobody has to track down all the resource files, measure for changes, run a script, verify the file formatting, and figure out issues like duplicate string IDs or silly things like a missing curly bracket in the file format. When the translation comes back, there is no need to manually check the files again, track the fact that some translations came back before others, find a missing translation, or some broken file parameter or encoding. That’s all done. If there’s an issue, it’s clearly described and the fix is fast. If as fallible humans we were to miss any of that, it’s often not detected till much later and even so, it can be hard to unravel. Because there is no human processing delay, linguistic testing can begin faster and within context of the application.

Integrating i18n and L10n has another human factor effect that changes the cultural thinking of the company. When measurement and updating is quick, visible, and relatively painless, you change the way that developers think about globalization requirements. You’ll find teams learn to automatically think about the global implications of their development efforts and the needs of new customers, and factor that into their decisions upfront. As one executive described it, the teams moved from being like a US based company that is looking to do international business, to a global mindset, looking to write software for the world. That makes for global product leadership, rather than a simple checkmark for minimal product requirements.

Strengthening Your Competitive Edge in Global Markets

Remember, there are competitors whose primary model is to copy what is successful in some markets, but use a better localized product to outcompete dominant industry players in new markets. Internationalization and localization are now not just about reaching new customers, they are also about defending customers and capitalizing on new opportunities going forward. What some people think is good enough, is not good enough. It’s best to give your global customers a continuous, excellent, up-to-date experience, or someone else will do that for you.

Learn How 800,000 Lines of Code Get Internationalized Efficiently for Global Markets

View the recording of this Lingoport-Vistatec webinar on agile internationalization and localization, with insights from special guests at CA Technologies, a $4 billion+ software firm helping companies to reimagine and shape the future.

CA’s Agile Central (formerly known as Rally) is the leading collaborative, enterprise SaaS platform for agile software development, and named the Leader in Gartner’s Magic Quadrant. With more than 800,000 lines of code, it is a complex application with high visibility – it’s even synonymous with Agile software management itself.

Navigating Complex Agile Development

The CA Agile Central team came to Lingoport and Vistatec to work together to internationalize and localize Agile Central software, while also putting in place analysis and automation systems to support both internationalization and localization in ongoing agile development. The globalization effort was performed in parallel with ongoing feature development and deployment, requiring the same agile approach for internationalization. The work included automated i18n checks, streamlining of resource file processing, and training of the dev teams.

Uncover the Lessons Learned

In this webinar, members of the CA team, together with Lingoport and Vistatec, explain how the work came together, lessons learned, and the path to streamlined, ongoing globalization.

Presenters

Shay Boudreaux – Principal Product Manager, CA

David Thompson – System Architect, CA

Lori Cameron – VP Internationalization Services, Lingoport

Suzanne Marie Frank, Director of Business Development – US, Vistatec

Webinar Recorded:

Tuesday, June 27thDuration: 30 minutes

What You Will Learn

Insight into scoping a large i18n project for a complex application

Opportunities to streamline the i18n and L10n process

Methods for overcoming obstacles in the process

Managing collaboration between development, i18n and L10n

How to leverage technology to build a super powered globalization team for ongoing software development success

Internationalization (i18n) and localization (L10n) are difficult undertakings prone to error. New i18n initiatives are rarely met with gleeful enthusiasm from all parties. Yet as companies expand their impact outside of their home markets, we’ve seen time and again that i18n and L10n are critical components. Through our experience, Lingoport has learned a great deal about how to make efforts less painful and even straightforward and positive, from initial i18n efforts to ongoing i18n and L10n support.

Lingoport originally started as an i18n services company. We continue to deliver several large-scale i18n projects each year over millions of lines of code. In this position, we’ve gained valuable cross organizational experience. We’re highlighting both the human and technology factors for initial and ongoing globalization efforts in our next webinar: Globalizing Your Product Development.

Highlights:

i18n and L10n business case and your company’s world outlook

Conflict between feature development schedules and globalization

Contrasting initial projects vs. ongoing globalization

New i18n and L10n effort procedures

Scoping with metrics and architectural views

Technical challenges and concurrent development

Technologies that reduce time and risk

Project phasing

Example costs

Ongoing i18n

Development cycles and agile emphasis

Integrating development, QA and localization

Your company’s G11n ecosystem

Successful examples

Questions and Answers

This webinar is lead by Adam Asnes, Lingoport’s CEO, and Lori Cameron, Lingoport’s VP of i18n Services.

Boulder, CO – February 1, 2017 – Lingoport has Globalyzer 5.3. Globalyzer is a keystone of the Lingoport product suite which integrates software internationalization (i18n) and localization (L10n) into every sprint and release. With companies launching and adapting their software for global markets faster than ever, there is a burden on delivering a high quality user experience that handles locale requirements gracefully, including language, cultural formatting and adaptability.

Globalyzer finds and fixes i18n issues as part of the continuous development process or can be run on existing source code. This helps software developers scale so that their products can elegantly perform in global markets that require support for translation and localization of formatting.

Highlights of the Globalyzer 5.3 new enhancements include:

i18n support for the Swift programming language, used in development for iOS platforms, including the iPhone and iPad

Enhancements to Perl i18n support

Enhancements to MVN support

“This Globalyzer release was in direct response to customer feedback and is important as we continue to support enterprise development teams. Their activities often includes many programming languages and development processes.” explained Olivier Libouban, Lingoport’s VP of Product Development.

“With the velocity of ongoing product development there is pressure to internationalize, enabling globalization across multiple user interfaces on desktops, browsers and mobile platforms.” added Adam Asnes, Lingoport CEO. “In each release, we seek to support nimble development, while bridging gaps between development, QA and localization.”

The Lingoport Suite makes both i18n and Localization activities visible, with direct navigation and processing for issues that would be otherwise hidden in volumes of code. The suite automates and verifies software globalization activities that are error prone and take time away from primary product development pursuits.

Lingoport provides a software and professional services that enable globally-focused companies to create and maintain products that work elegantly in every language and locale. See http://lingoport.com.

Lingoport has released a new edition of its product suite. The Lingoport Suite integrates software internationalization (i18n) and localization (L10n) into everyday software development activities. With companies launching and adapting their software for global markets faster than ever, there is a burden on delivering a high quality user experience that handles locale requirements gracefully, including language, cultural formatting and adaptability.

LRM automates translation updates in line with new software development within each sprint and release. The automation and verification provided by LRM, make the otherwise tedious process of extracting and committing localization updates to source code easy and simple. No more chasing files for momentum-killing iterative updates. Multilingual QA activities are also automatically facilitated. LRM 3.1 features include:

Support for ICU MessageFormat (i.e. pluralization and gender variables)

Further hyperlinks within Dashboard data sections, providing greater ease of use

Faster drill down analysis of remediation issues and completion

More historical analysis functionality

For more release information, please see: http://wiki.lingoport.com/LRM_Release_Notes and http://wiki.lingoport.com/Dashboard_Release_Notes.
“Most developers do not start their day looking forward to chasing down and managing files that will need localization updates for each sprint. When you multiply that times the amount of development teams and frequent iterations, the problem begs for automation. This eliminates human error, handling time and additional human factors like putting off localization in favor of other development.” explained Adam Asnes, Lingoport CEO. “These updates and globalization issues are important. You need to be able to instantly see and manage them as well as automate and compress their timing. This way you avoid treating global customers like second class users by letting new features fall behind.”

Lingoport provides software and professional services that enable globally-focused companies to create and maintain products that work elegantly in every language and locale. The Lingoport Suite includes Globalyzer, Lingoport Resource Manager and Lingoport Dashboard, working together to simplify internationalization and localization of source code in every sprint and release. For more details, please visit http://lingoport.com.

Ever wonder about how good people are at understanding and using technology? It’s worse than you probably think. So says a study recently published by the Nielsen Norman Group (Evidence-Based User Experience Research, Training, and Consulting). I suggest that anyone having to do with the making and localization of software take a look at this compelling and well written abstract: https://www.nngroup.com/articles/computer-skill-levels/

The short version:Across 33 rich countries, only 5% of the population has high computer-related abilities, and only a third of people can complete medium-complexity tasks.

Taken from this article: https://www.nngroup.com/articles/computer-skill-levels/

The study breaks down user abilities into 3 distinct levels of task performing proficiencies, plus an additional sub-level of “can’t use computers”. The data was collected from 2011–2015 in 33 countries and was published in 2016 by the Organisation for Economic Co-operation and Development, a club of industrialized countries. In total, 215,942 people were tested, with at least 5,000 participants in most countries. Don’t worry, If you’re reading this, you’re probably in level 3.

If you add language or cultural formatting issues into the equation, it’s a safe bet that skills would skew in an even more negative direction. Poor user experience, for which localization is a considerable factor, makes for bad business. It raises sales and support costs, decreases user loyalty, and can reduce or even nullify competitive advantages.

My personal evidence from running a company that provides enterprise software is that even with technology savvy clients, plenty of people working in positions demanding computer proficiency don’t necessarily have the skills you’d think they should. Inevitably, misunderstandings happen. It’s very easy to overestimate user knowledge skills.

In working with many software companies over the years, we’ve seen that developers don’t necessarily understand internationalization and localization issues – even if they get the basics. For example, You can instruct developers to always externalize strings, only for them to externalize sentence fragments that they later concatenate programmatically. As word order, word gender and pluralization rules change, concatenation methods that worked in English will instead produce garbled and nonsensical sentences.

As another example, Calendar classes might not be provided with locale information. Or a font that won’t work in Chinese may be embedded. There are tons of issues like this, many that are difficult to find in testing. The whole process becomes more complicated and impactful when you have multiple teams that may be distributed over geography driven on fast moving deliverables.

Our customers agree, it’s important to continuously check software as it’s being written for internationalization (i18n) issues. Likewise, integrating ongoing localization (L10n) automation into developer workflow is imperative. Otherwise you fall behind, bugs get lost in testing, or worse – problems fall into a black hole backlog. You get a better product and user experience, in less time and less hassle if you make i18n & L10n an automatically measured, managed and visible part of each sprint and release.