Adding Cultures after Go-Live

xtensibilitybro
New Contributor III

Hi All,

I was wondering if anyone had experience adding cultures to an applicaiton after go-live. Considering this is a system wide change its difficult to test without applying across all applications. I'm wondering if the statement in the attached screenshot "impact overall environment or application performance" would be applicable to adding new cultures. 

Looking forward to hearing from you all.

Cheers!Cultures.PNG

1 ACCEPTED SOLUTION

ChrisLoran
Valued Contributor

This is similar to an existing enhancement request PF-26868.
Unfortunately you can't add custom culture codes ( well, you can in the server config, but they won't actually appear in the application unless they are one of the standard culture codes as set my Microsoft )
If it is only a few variations of descriptions, then you could use some other "English" culture codes like en-AU, en-CA, en-CB, en-IE, en-NA, en-GB, en-ZA , and get your cube views to display the correct one depending on the entity.

You could of course do something more custom, using XFBR/BRString in the :Name override in the Cube View Rows/Columns, but then this won't work so well if you are using member expansions like A#BS.Tree, A#PL.Descendants.  A DynamicCalc on the V#Annotation (or other text-based view member) could also be used to show alternate descriptions based on some lookup logic, but will probably have a negative impact on performance.

View solution in original post

8 REPLIES 8

ChrisLoran
Valued Contributor

Adding culture codes doesn't directly affect performance, but it may cause business rules (and possibly some Marketplace solutions) to stop working suddenly, if a user with a non-US culture code logs in and runs consolidations.

If you have any calculation formula/rules that try to append a Decimal variable to a calculation string, and you don't explicitly state the Invariant culture in the calculation, then these calculations will certainly fail for any non-US users.
There is still a big myth out there that just because the calculations may be running on a server in the US, that culture code settings only affect the front-end view/reporting output etc.  I wish that were true, but it's not.

The danger is not adding culture codes after go-live.  The danger is assigning an active user to a non-US culture code, and having them run calculations/consolidations, unless the rules are checked and double-checked to work properly when initiated by such users.

JackLacava
Community Manager
Community Manager

That documentation warning is generic. Basically, if you modify app server settings with the utility, they all get saved in a single file in one go; so if you went in to modify cultures and by accident deleted a database connection while doing so, you'd be screwing up your environment.

Adding cultures, by itself, is a relatively safe operation; the only real gotcha from a performance perspective is what @ChrisLoran mentioned. I'm writing a blog post on techniques to address that point, stay tuned 😎

Other bits that might be affected: if you provide localized descriptions for some of your metadata members but not all of them, your cube views and dashboards might end up showing a mixture of languages, which is not a good look from a professional perspective - so plan for that (i.e. do all the work in dev, then load updated metadata in prod as soon as you enable a new culture).

ChrisLoran
Valued Contributor

In a nutshell:
These will all fail, if the calculation is invoked by a user that has a non-English culture setting:

'-- Bad , never do this... --
Dim somePrice As Decimal = 123.45
api.Data.Calculate("A#Result = A#Qty * " & somePrice)

also this is a big no-no , for the same reason

Dim somePrice As Decimal = 123.45
api.Data.Calculate( $"A#Result = A#Qty * {somePrice}" )

And so is this:

Dim somePrice As Decimal = 123.45
api.Data.Calculate( String.Format("A#Result = A#Qty * {0}", somePrice ) )

 All three examples above will either produce a runtime error, or cause incorrect calculation results, when the calculation is initiated by a user with a non-English culture setting (where their local reporting uses comma as the decimal instead of dot).

ChrisLoran
Valued Contributor

On the flip-side of the above examples:
This use of XFToStringForFormula  will work for all culture codes, but suffers from accuracy because it truncates to 9 decimal places in the calculation:

Dim someRate As Decimal = 0.00000001234567
api.Data.Calculate( "A#Result = A#Qty * " &  someRate.XFToStringForFormula()  )

 The best way to combine Decimal amounts with a calculation, is to use Formula Variables:

Dim someRate As Decimal = 0.00000001234567
api.Data.FormulaVariables.SetDecimalVariable("someRate", someRate)
api.Data.Calculate("A#MyResult = A#Quantity * $someRate")

* Works for all culture codes
* Doesn't have the overhead of converting Decimals to Strings
* Doesn't suffer the consequences of trying to present numbers as strings in various culture settings

ChrisLoran
Valued Contributor

Lastly, you need to review your application to see if there are any assumptions on Date Formats.
This is especially true if your application is using a Specialty Mktplace solution (e.g. People Planning) and you need to retrieve dates from a register table, or any other relational table in your application.
I've lost count the number of applications where there was an assumption that dates would be retrieved and interpreted as US date format (mm/dd/yyyy) and I've even seen people hard-code assumptions into the way their rules break up these date strings into components.   The best application is one where you never use strings to represent dates.

xtensibilitybro
New Contributor III

Thank you @ChrisLoran and @JackLacava for the speedy replies. This is all very valuable information. The reason I was hoping to use cultures is to allow the descriptions of accounts to change depending on the specific entity group I'm looking at. For example, one group might have a single "Loan Payable" where another might have multiple therefor it would be named "Loans Payable". I was thinking culture would be a better use rather than recreating each of the cube views and manually renaming each row as this would lose the dynamic aspect of member expansion functions. 

 

I guess my next question is, are there custom cultures where the only purpose it to leverage them in a cube view parameter to vary the account description. All of the users will be setup as English (United States).

Thank you,

Amar

ChrisLoran
Valued Contributor

This is similar to an existing enhancement request PF-26868.
Unfortunately you can't add custom culture codes ( well, you can in the server config, but they won't actually appear in the application unless they are one of the standard culture codes as set my Microsoft )
If it is only a few variations of descriptions, then you could use some other "English" culture codes like en-AU, en-CA, en-CB, en-IE, en-NA, en-GB, en-ZA , and get your cube views to display the correct one depending on the entity.

You could of course do something more custom, using XFBR/BRString in the :Name override in the Cube View Rows/Columns, but then this won't work so well if you are using member expansions like A#BS.Tree, A#PL.Descendants.  A DynamicCalc on the V#Annotation (or other text-based view member) could also be used to show alternate descriptions based on some lookup logic, but will probably have a negative impact on performance.