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 General Pattern Scan Rules for more details.

How does Globalyzer deal with "False Positives"?

In internationalization (i18n) efforts, "False Positives" are detected issues that are not actually i18n issues. For example, a programmatic string may be detected by Globalyzer, but since it will not display to a user, it does not require translation and so is a "False Positive". Globalyzer's Default Rule Sets come with filter Rules that are tailored for each programming language, filtering out many "False Positives" on the first Scan. In addition, each time we release a new version of Globalyzer, we try to add more default filter Rules to help speed up the customization you will need to do for your specific application.

Is there support for detecting and fixing 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.

How should I fix locale-sensitive Static File references?

Static Files that might contain internationalization issues are usually handled by duplicating the files and locating them in locale-sensitive directories. The code is then refactored to retrieve the file based on the user's locale. Some examples of locale-sensitive static files are images with text, help files, video files, HTML files, and xml files that contain displayable text.

Globalyzer's Static File Reference Scan will scan the source code for references to these types of static files. After you've filtered out the false positives, you'll need to refactor the references so that they use the locale to determine which static file to load.

Will Globalyzer automatically externalize embedded strings?

Globalyzer has the capability of externalizing an unlimited number of embedded strings with just a few keystrokes. However, once you select the strings you want to externalize, you may view each reported issue in a snippet of the code and exclude it from the externalization process as needed. While batch externalization is a huge time-saver in your internationalization process, we do recommend checking the strings carefully first.

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.

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