agile i18n Archives

Posts

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

May 18, 2018/0 Comments/in Blog /by Matt Deragisch

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.

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.

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.

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.

Globalyzer 6.1

May 17, 2018/0 Comments/in Blog /by Matt Deragisch

Machine Learning and New Bot Assistance Enhance Software Internationalization

Lingoport is releasing a major update to Globalyzer, which helps globally focused technology companies develop software that is internationalized to support worldwide languages and cultural formats. The release leverages machine learning to help developers pinpoint internationalization (i18n) issues in code faster, with more intuitive controls.

Lingoport’s Globalyzer 6.1 Release improvements include:

Machine Learning to fine tune internalization error detection within software
Ability to customize the string comparison dictionary
Lingobot access via developer IDE
Rule Set Importing Enhancements

Machine Learning

Machine learning capabilities add a whole new and exciting method to address false positives that occur when first setting up and tuning Globalyzer i18n code scans. I18n issues can be initially misleading; as they can be conditional depending upon coding context. The ability to save time during internationalization tuning is compounded as machine learning is conditioned by user input. The team will mark logged errors as true or false as they progress through reports which will improve the reporting of future results.

“Managing false positives is the number one concern we hear from developers, so it’s exciting that our team has built a new approach that’s easy, straightforward and even a little addictive to use.” stated Adam Asnes, Lingoport’s CEO. “With Machine Learning, Globalyzer becomes even more adaptable for the speed of agile development globalization.”

You can see Globalyzer’s machine learning in action here.

Customizable Dictionary Detection

Bolstering the user’s ability to combat false positives includes updates to Globalyzer’s dictionary comparison functionality. Users can now update the default dictionary and ensure that any approved language doesn’t populate as an error during reporting. Coupled with the improvements of Machine Learning users have enormous control over error reporting.

Lingobot from within the IDE

Developers will be able to access Lingobot, which helps users launch batch Globalyzer and Resource Manager functions, from within their development application or IDE (Integrated Development Environment). Common actions include pushing new content for localization, checking the status of a current project, and running a check on the code for internationalization errors.

This new Lingobot extension offers a drop-down menu that can be plugged into the interface which can access all the same functionality. The same functionality can be accessed via command line interaction as well, allowing developers to choose whichever method to access the tools of Globalyzer that works best for them. Lingobot was previously accessible via collaboration tools such as Slack, which for some Lingoport customers, were prohibited due to IT security policies.

You can read more about this Lingobot feature here.

Globalyzer 6.1 also features bulk rule set imports, terminology improvements and bug fixes.

The release notes for Globalyzer 6.1 can be read here.

Please feel free to contact us with any questions or comments you have about this release.

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

April 19, 2018/0 Comments/in Blog, Internationalization /by Matt Deragisch

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

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.

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.

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

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

What if this could automatically be solved?

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

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

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

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

Throwing it Over the Wall

February 16, 2018/0 Comments/in Blog /by Matt Deragisch

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.

Tag Archive for: agile i18n