IBM Support

With some particular locales, the Viewer of Planning Analytics for Excel does not use correct format (decimal separator and thousand separator)

Troubleshooting


Problem

With some particular locales, for example "English (Belgium)", Planning Analytics for Excel is able to display correct decimal and thousand characters [respectively comma and point for "English (Belgium)"] as long as this is in the Excel sheet.
But when opening a view in the Viewer (by using right-click "Open Viewer"), the decimal and thousand separators are not correct anymore.

Cause

Some locales that are listed in Windows Regional Settings, are not actual supported locales.

     Although we can see "English (Belgium)" in the "Format" tab of the Windows Regional Settings (intl.cpl), we cannot see it in the list of supported locales when, for example, we want to change the Windows "System Locale":

image 11531

As we can see in this screenshot, "English (Belgium)" is not listed.

This locale is not either listed in Chrome nor Firefox.

This is because en-BE is not an actual locale: it just translates to unspecified custom locale.

     Windows somehow manages to apply these "false" locales on thick client tools like Excel, but the "Viewer" is a web component (that is part of Planning Analytics Workspace in the background) so it applies the web client rules (and again: these unsupported locales are not listed in Chrome and Firefox)

As per this document from Microsoft, it is advisable to not use or process these locales and simply discard them:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-lcid/926e694f-1797-4418-a922-343d1c5e91a6

"

     When an LCID is requested for a locale without a permanent LCID assignment, nor a temporary assignment as above, the protocol will respond with LOCALE_CUSTOM_UNSPECIFIED for all such locales. Because this single value is used for numerous possible locale names, it is impossible to round trip this locale, even temporarily. Applications should discard this value as soon as possible and never persist it. If the system is forced to respond to a request for LCID_CUSTOM_UNSPECIFIED, it will fall back to the current user locale. This is often incorrect but may prevent an application or component from failing. As the meaning of this temporary LCID is unstable, it should never be used for interchange or persisted data. This is a 1-to-many relationship that is very unstable.

"

     In short, the Locale id is the same for many other Locales. If we check other locales they will have the same Id.  TM1 cannot process en-BE therefore we do not see the proper format there:

e.g.:

Aghem Cameroon 0x1000 agq-CM

Has the same id as:

English Belgium 0x1000 en-BE

Resolving The Problem

It is recommended to choose a proper supported locale rather than a pseudo custom locale that even Microsoft advises applications to discard.
For "English (Belgium)" a possible workaround could be to use "English (South Africa)" instead, which is supported and uses the same separators.

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSD29G","label":"IBM Planning Analytics"},"ARM Category":[{"code":"a8m50000000KzIzAAK","label":"Planning Analytics Workspace"},{"code":"a8m50000000KzJ4AAK","label":"Planning Analytics for Microsoft Excel"},{"code":"a8m0z000000blfjAAA","label":"Troubleshooting"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
24 September 2021

UID

ibm16492365

Page Feedback