Scanning and Filtering FAQ

Can I use Globalyzer to look for issues in my code that have nothing to do with internationalization?

Yes. In fact this is quite common. One of the added values that our customers use Globalyzer for is as a repository for regular expression searches, which they can name, describe and share among their company’s developers. See Rule Sets and scroll down to General Pattern Scan Rules for more details.

Is there support for detecting GUI alignment problems?

This would be handled adding new General Pattern Rules to your Rule Set that detect fixed widths.

What is the difference between the “Ignore” and “Invalid” Status?

These status choices can have any meaning, and are just a way to further break up the scan results. That said, we think that the Invalid status should be used in the cases where the scan detection is not correct. For example, say Globalyzer’s Embedded String scan found a detection that wasn’t a UI embedded string (for example, a programmatic string). In this case, you would set the result to the Invalid status. The Ignore status, on the other hand, would be used for embedded strings that do appear in the UI but that you don’t translate, for example, file extensions or program names. The TODO is another status that you could apply to scan results that you want to deal with at a later time. In the case of the Locale-Sensitive Method scan, you could apply the Ignore status to results where the method usage is not an issue and use the TODO status if you want to look at the method later.

How does Globalyzer determine whether or not an embedded string is an internationalization issue?

During the Embedded String scanning process, Globalyzer will detect all strings in the source code. Then, the Globalyzer filters are used to eliminate the programmatic strings, or strings that would not require translation. So, the scanning work is primarily in filtering out strings, rather than in detecting them.

How should I filter false positive issues?

Two of Globalyzer's main benefits are first in detecting possible internationalization (i18n) issues, and then in helping you hone down that list to only issues that will actually need code modifications to fix. There are three approaches that Globalyzer provides to address false positive issues in your Scan Results:

1. Add filter rules to your Rule Set so that the next time you scan, Globalyzer will filter out those false positive detections. Since Rule Sets can be shared among team members and applied to any source code, this is a way to make a large scale effect with little effort and is our first recommendation for filtering Scan Results.

2. Change the Scan Results Status of false positive issues to be Invalid or Ignore. The Status settings are stored with the scanning results in Globalyzer's Client database on your local machine, so as long as you don't delete your scan results or modify the source code file significantly, the Status settings will be maintained during subsequent scans. We recommend this approach when there are specific results that you need to filter that don't lend themselves to Rule Set filters, and when developers prefer that you do not modify source code.

3. The last approach is to use one of the Ignore Comment options, which modifies the source code, and so is the most permanent resolution. Regardless whether a Rule Set filter is modified or Scan Results are deleted, or the source code file is significantly modified, Globalyzer will detect the ignore comment in the source code and skip over one or more lines of code that contain false positive i18n issues.

In addition, Globalyzer's Dictionary, enabled by default in the Window->Preferences->Globalyzer page, helps to filter and prioritize the Embedded Strings that are detected. For example, strings will be filtered if there are no matching Dictionary words. Conversely, depending on the number of matching versus non-matching words as well as other applied heuristics, Globalyzer will set the priority of each Scan Result, which aids in determining which strings will most likely be translatable strings.

Can you tell me more about inserting comments in my source code so that Globalyzer does not detect programmatic strings?

There are several kinds of Ignore comments that you can insert in your source code to tell Globalyzer to "ignore" scanning and therefore omit programmatic strings from the Scan Results.

1. You can insert a comment in the source code that indicates the next line does not require scanning. The comment itself is customizable in Globalyzer's project properties setting. By default it is GLOBALYZER_IGNORE_NEXT_LINE.

2. You can tell Globalyzer to skip scanning a block of code by using a comment to start and a comment to end the "skipped block". These comment commands are also customizable. By default, the keywords are: GLOBALYZER_START_IGNORE and GLOBALYZER_END_IGNORE.

3. Another way is to use Eclipse style comments. You select the rows that you want to ignore in the Scan Results table. Then right-click and choose Ignore this Issue. Globalyzer will insert comments of the form $NON-NLS-[n]$ at the end of the line, where "n" refers to the nth issue on the line. For example, if there were 2 embedded strings on the line that you wanted to ignore, Globalyzer would insert: $NON-NLS-1$ $NON-NLS-2$ for the two times that you chose Ignore this Issue.

4. To ignore all the issues on a line, choose Ignore this Line. Globalyzer will insert comments with $NON-NLS-L$ comments at the end of the line. Subsequent scans will ignore the lines with $NON-NLS-L$ comments.

5. Globalyzer also has a way to ignore issues without modifying the source – using the Status setting in the Scan Results view. As long as the files don’t change too much, the “soft ignore” will work. Note that if you want to share your Status settings with other team members, you will need to export your Globalyzer Project (with Scan Results checked) and then they will need to import the project. You will also need to make sure that the Globalyzer Server Rule Sets used by the project are set to shared so that they're available to the entire team.

Could you provide some sense of scanning performance?

Performance will depend on the machine running the scans. Lingoport performance tests are geared towards a Continuous Globalization process where a Jenkins type system executes scanning jobs. The following gives a performance benchmark for a specific machines on the two major operations when running in a Continuous Globalyzer:

• Login in
• Running the scans, with or without rule sets reload

Benchmark System Info:
   Operating System Name: Windows 8.1
   Operating System Type: amd64
   Operating System Version: 6.3
   Processor Identifier: Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
   Number of Processors: 4
   Available processors (cores): 4
   Free memory (bytes): 79497416
   Maximum memory (bytes): 1407713280
   Total memory (bytes): 94896128
   Number of Rule Sets: 10

Login Benchmark: 559 milliseconds
Login Benchmark: 324 milliseconds
Login Benchmark: 336 milliseconds
Login Benchmark: 313 milliseconds
Login Benchmark: 307 milliseconds
Login Benchmark: 306 milliseconds
Login Benchmark: 313 milliseconds
Login Benchmark: 300 milliseconds
Login Benchmark: 303 milliseconds
Login Benchmark: 290 milliseconds


Execute Java Scan Benchmark (927 lines of code, 9 files, 190 active results):
Reloaded rule sets
Executing java scan: 2073 milliseconds
Executing java scan: 746 milliseconds
Executing java scan: 557 milliseconds
Executing java scan: 553 milliseconds
Executing java scan: 533 milliseconds
Executing java scan: 541 milliseconds
Executing java scan: 520 milliseconds
Executing java scan: 513 milliseconds
Executing java scan: 524 milliseconds
Executing java scan: 516 milliseconds
Reloaded rule sets
Executing java scan: 652 milliseconds
Executing java scan: 574 milliseconds
Executing java scan: 526 milliseconds
Executing java scan: 493 milliseconds
Executing java scan: 488 milliseconds
Executing java scan: 499 milliseconds
Executing java scan: 486 milliseconds
Executing java scan: 481 milliseconds
Executing java scan: 475 milliseconds
Executing java scan: 470 milliseconds
Reloaded rule sets
Executing java scan: 611 milliseconds
Executing java scan: 478 milliseconds
Executing java scan: 465 milliseconds
Executing java scan: 472 milliseconds
Executing java scan: 464 milliseconds
Executing java scan: 483 milliseconds
Executing java scan: 469 milliseconds
Executing java scan: 455 milliseconds
Executing java scan: 459 milliseconds
Executing java scan: 459 milliseconds