<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.lingoport.com/index.php?action=history&amp;feed=atom&amp;title=Globalyzer_5.1_Features</id>
	<title>Globalyzer 5.1 Features - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.lingoport.com/index.php?action=history&amp;feed=atom&amp;title=Globalyzer_5.1_Features"/>
	<link rel="alternate" type="text/html" href="https://wiki.lingoport.com/index.php?title=Globalyzer_5.1_Features&amp;action=history"/>
	<updated>2026-04-30T21:08:17Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.43.3</generator>
	<entry>
		<id>https://wiki.lingoport.com/index.php?title=Globalyzer_5.1_Features&amp;diff=87856&amp;oldid=prev</id>
		<title>Olibouban: Created page with &quot;== Locale-Sensitive Method enhancement ==  There are two new fields when configuring Locale-Sensitive Methods for Java: Class or Variable Type and Parameter Type(s) to Filter....&quot;</title>
		<link rel="alternate" type="text/html" href="https://wiki.lingoport.com/index.php?title=Globalyzer_5.1_Features&amp;diff=87856&amp;oldid=prev"/>
		<updated>2016-04-01T17:13:26Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;== Locale-Sensitive Method enhancement ==  There are two new fields when configuring Locale-Sensitive Methods for Java: Class or Variable Type and Parameter Type(s) to Filter....&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;== Locale-Sensitive Method enhancement ==&lt;br /&gt;
&lt;br /&gt;
There are two new fields when configuring Locale-Sensitive Methods for Java:&lt;br /&gt;
Class or Variable Type and Parameter Type(s) to Filter.&lt;br /&gt;
If the Class or Variable Type is specified, then only method calls called via this class will be detected.&lt;br /&gt;
If Parameter Type(s) to Filter is specified, then if one of the arguments is of the specified type, the Locale-Sensitive Method willnot be detected.&lt;br /&gt;
&lt;br /&gt;
Let&amp;#039;s say you want to detect toUpperCase calls for Java Strings, but not if the Locale is specified. You would configure:&lt;br /&gt;
&lt;br /&gt;
     Pattern: toUpperCase&lt;br /&gt;
     Class or Variable Type: java.lang.String&lt;br /&gt;
     Parameter Type(s) to Filter: java.util.Locale&lt;br /&gt;
&lt;br /&gt;
If Class or Variable Type is blank, then all toUpperCase calls will be detected (if not filtered by Parameter Type).&lt;br /&gt;
If Parameter Type(s) to Filter is blank, then no subsequent filtering will take place.&lt;br /&gt;
If multiple Parameter Type(s) are specified, then if one matches, filtering will take place.&lt;br /&gt;
&lt;br /&gt;
Note that only one Class or Variable Type can be specified (which is different from String Method Patterns/Filters). This is because we want the help to be one for one, and we want the Parameter Type(s) to be for a particular method.&lt;br /&gt;
Note also that before, patterns needed to be unique. Now class/pattern needs to be unique.&lt;br /&gt;
So, for instance, you can specify:&lt;br /&gt;
&lt;br /&gt;
     Pattern: getInstance&lt;br /&gt;
     Class or Variable Type: java.util.Collator&lt;br /&gt;
&lt;br /&gt;
and:&lt;br /&gt;
&lt;br /&gt;
     Pattern: getInstance&lt;br /&gt;
     Class or Variable Type: java.text.DateFormat&lt;br /&gt;
&lt;br /&gt;
Each of these entries can have their own  help and can specify different parameters to filter against.&lt;br /&gt;
&lt;br /&gt;
One other change regarding Locale-Sensitive Methods is that the content of the reason field has changed. It used to contain the group name. Now it contains group name, method name, and class name formatted as below:&lt;br /&gt;
&lt;br /&gt;
     group:method-class&lt;br /&gt;
&lt;br /&gt;
If a class hasn&amp;#039;t been specified:&lt;br /&gt;
&lt;br /&gt;
     group:method&lt;br /&gt;
&lt;br /&gt;
As part of upgrading your server, you will run a migration script to update the default Java rule set. When creating a new Java rule set, you will see the new rule configurations that make use of the new Class and Parameter fields. If you would like to upgrade an existing Java rule set, you need to do this group by group. Select your rule set, select Configure Locale-Sensitive Methods, click on a Group name to show the methods in that group, and then click on Add Locale-Sensitive Method Defaults (at the top of the page). This will bring in the new defaults, unchecked, for that group. You can check them to enable them and then delete the old rules. You will need to do this for each group.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Upgraded API==&lt;br /&gt;
&lt;br /&gt;
Added a new setSessionSettings() method that allows you to specify the following:&lt;br /&gt;
    data dictionary location (default is {userhome}/.globalyzer)&lt;br /&gt;
    whether or not to filter against the dictionary (default is true)&lt;br /&gt;
    set the scan timeout - the length of time to wait before determining&lt;br /&gt;
                                          that a file scan is taking too long (default is 120 seconds)&lt;br /&gt;
This would be called before login().&lt;br /&gt;
&lt;br /&gt;
Also added new signatures for createScan() and createProjectScans() that allow you to specify some of the scan details that you can configure when using the Workbench. You can specify source file encoding, types to scan (Embedded Strings, Locale-Sensitive Methods, General Patterns, Static File References), and comment text.&lt;br /&gt;
&lt;br /&gt;
==Upgraded Lite==&lt;br /&gt;
&lt;br /&gt;
===Passwords and Login Info in a .globalyzerrc===&lt;br /&gt;
You can now set default login information for Globalyzer Lite by creating a .globalyzerrc file. It&amp;#039;s now optional to specify login information within project definition files. With an exception that the Globalyzer Server URL is still required. The .globalyzerrc is not a required file. Settings within project definition files override those within the .globalyzerrc file.&lt;br /&gt;
Note: If you are using a .globalyzerrc file, you still must set a Globalyzer Server URL within your project definition file(s). If the URL set in these file(s) does not match the URL set in your .globalyzerrc, Globalyzer Lite will refuse to scan the project. This helps to verify that your project is scanned using rule set information from the correct server.&lt;br /&gt;
&lt;br /&gt;
===Custom Scan Timeout===&lt;br /&gt;
By default, Globalyzer skips files which take longer than 2 minutes to scan. You may now set the timeout duration yourself. It can be anywhere from a few seconds up to 5 minutes.&lt;br /&gt;
&lt;br /&gt;
===Additional Scan Customizations===&lt;br /&gt;
You may now choose which issue types to scan for. For instance, you might wish to ignore all embedded string issues. Or to scan for only locale sensitive methods.&lt;br /&gt;
In Lite 5.1, you may now specify custom values for Globalyzer comments. These comments tell Globalyzer to ignore a section of code, or to mark an issues as &amp;#039;TODO&amp;#039;. One use for this feature is ignoring sections of test code within a project. For instance, given a C++ project you could change &amp;#039;GLOBALYZER_START_IGNORE&amp;#039; to &amp;#039;#ifdef EMBEDDED_TEST&amp;#039; and &amp;#039;GLOBALYZER_END_IGNORE&amp;#039; to &amp;#039;#endif // EMBEDDED_TEST&amp;#039;. Effectively ignoring test code within the project.&lt;br /&gt;
You can specify the expected file encoding for each scan. No matter which encoding your source files are saved in, Globalyzer Lite will be able to scan them.&lt;br /&gt;
&lt;br /&gt;
===Globalyzer Lite Dictionary Settings===&lt;br /&gt;
Globalyzer Lite now allows you to disable dictionary-based scanning. Dictionary based scanning helps Globalyzer filter out issues which don&amp;#039;t contain English words. This setting is helpful if you want to see issues containing only non-english words.&lt;br /&gt;
Lite allows you to specify a custom location to save its dictionary information to.&lt;/div&gt;</summary>
		<author><name>Olibouban</name></author>
	</entry>
</feed>