Adding Cultures after Go-Live

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.

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

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).

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).

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.

Building International Applications - October 2022 - OneStream Community (onestreamsoftware.com)

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