Scanning and Filtering FAQ

Scanning and Filtering

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 can I tell if I am using the correct method call for a supported locale?

For many of its supported languages, Globalyzer will provide you with information and direction for refactoring methods and functions, giving examples and cross references when appropriate. It’s probably the largest on-line internationalization help system existing anywhere.

Will Globalyzer help me adapt my application to support Unicode?

Yes, as is necessary to your particular programming language. You will have a number of character encoding support choices.

Rule Sets

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.

Can I modify the Default Rule Sets?

If you have a Globalyzer Team Server license, you will be hosting the Globalyzer Server, and as the Administrator, you can modify any of the Default Rule Sets.

If you are running from Lingoport's Globalyzer Server, you will not be able to modify the Default Rule Sets, but you can modify one of your own Rule Sets and then allow your team members to either use it (sharing) or copy it. This Rule Set can then be the starting point for their internationalization scanning and filtering process.

Where can I find more introduction and materials about “General Pattern” issues found in C++ code scanning?

If you go to the Globalyzer Server and look at the General Patterns for your rule set, it will often give information on why Globalyzer is scanning for this pattern. In addition, if you go to the Help system on the Globalyzer Server, there are various topics on C++ internationalization. In particular, click on Reference->Locale-Sensitive Methods->C++ Programming Language->C++ Rule Sets. This help page talks about Unicode support in the various C++ rule sets. For example, usually a C++ program will be compiled with single-byte character strings. These single-bytes cannot support Unicode characters, which require more than 1 byte. That is a main reason why our C++ General Patterns scan for character strings: because you will have to make sure to modify them if they are to hold Unicode strings.

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.

JavaScript Filtering

Does Globalyzer fix JavaScript locale-sensitive method issues?

Globalyzer detects methods that could be an issue when supporting multiple languages, but has no specific fixing built in. This is because it’s not always clear that the method is an actual issue and the fix may involve some reworking that requires manual decisions. However, for some programming languages, we have written internationalization (i18n) help for the method that explains the reason for the detection as well as suggestions on what change might need to be made. When we don’t provide specific i18n help, we provide links to external help on the method, which sometimes provide information about i18n considerations.

What is the fix for the JavaScript locale-sensitive method charAt()?

In this case, Globalyzer detected charAt because it is a method that indexes into a string. If that string contains a translation, then the location of the character may have changed or it may not be the same character. The fix is really dependent on the usage. If the string is locale-independent, then you can insert an Ignore This Line comment so that Globalyzer will no longer flag this issue.

When when internationalization help be added for JavaScript locale-sensitive methods?

We are always pressed to get more features into Globalyzer, but do try to spend as much time as possible adding to the help. We could add help for JavaScript in our next release. In the meantime, if you have any specific questions, you should email support@lingoport.com and we’ll get an answer for you right away!

Are there new JavaScript api’s available for these violations, or have you developed in house solutions for fixing these?

While Globalyzer doesn’t fix your method issues for you, it does allow you to document your resolutions directly in the Globalyzer Rule Set. For example, if you are an enterprise client, you can modify the default locale-sensitive methods for each programming language so that your users will also see your help modifications. If you’re using our hosted globalyzer.com, you can modify the locale-sensitive methods of a specific Rule Set that you create and then share that with other Globalyzer users that are part of your team. That way, once you do resolve an issue, others can benefit from your work.