Locale-Sensitive JavaScript Method

date.format(format);
number.format(format);
String.format(format, argsArray);
intlDateTimeFormat.format(date);
intlNumberFormat.format(number);


Internationalization (I18n) Method Overview

The first two format methods listed above return a date or number formatted string based on the format parameter. String.format is a static method that returns a string based on the format parameter with its insertion points replaced by dynamic variables passed in the argsArray. For all of these methods, the current Culture (Locale) is not used; in other words, regardless the locale, the resulting string will look the same. Microsoft refers to this "locale-insensitive" locale as the invariant culture.

Note that these 3 methods are Microsoft JavaScript Extended methods that require the .NET Framework. For additional method details, click here (Date), here (Number) and here (String).

The last two format methods in the list is a regular JavaScript method and is dependent on first constructing either an Intl.DateTimeFormat object an or Intl.NumberFormat object, passing in locale, and then calling its format method.

Click here (MDN) for additional details on intlDateTimeFormat.format, and here (MDN) for details on intlNumberFormat.format.

I18n Issues

Whether or not calling format is an i18n issue is dependent on how it is being used in the application. In the case of the JavaScript Extension methods, if the current Culture should be used because the resulting string is displayed to the user, then these methods should not be called.

The intlNumberFormat.format and intlDateFormat.format calls do support locale, so the only i18n issue would be if the method is not being called with the locale parameter, or is passing in the wrong locale.

Suggested Replacement

For the JavaScript Extended method calls, ensure that the current culture is used for data formatting rather than the invariant culture by calling localeFormat.

For intlNumberFormat.format calls, ensure that the correct locale is passed into the Intl.NumberFormat constructor so that the number will be formatted based on the locale.

Similarly, in the case of intlDateTimeFormat.format calls, ensure that the correct locale is passed into the Intl.DateTimeFormat constructor so that the date/time will be formatted based on the locale.

Globalyzer will detect this method and report it as an i18n issue. If you have determined that the call is being handled correctly, you can use Globalyzer's Ignore Comment functionality to ensure that it isn't picked up in a subsequent scan.