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
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.