Question about Culture:RFC5646 and ContentDefinitions - azure-ad-b2c

Question

{Culture:RFC5646} is returning two different values for English. Currently, when a user uses ProfileEdit or SignUpSignIn they are returning different values.
For example:
ProfileEdit returns: en-us
SignUpSignIn returns: en
I am using this in the LoadUri of ContentDefinitions so that we can have the user redirected to a customized and translated html page. However, with the two return values I am having to maintain two directories "/en" and "/en-us" instead of one.
I have verified that all the parent and child policies ContentDefinition's LoadURIs are using {Culture:RFC5646}.
We have tested multiple users from different locations.
I have researched the Azure B2C IEF localization documents, and it makes a reference to how the language is determined but it does not shed light on why the same user, with the same browser will return different values for {Culture:RFC5646}
Here is the Content Definition Load Uri for SignUpSignIn
<ContentDefinition Id="api.localaccountsignup">
<LoadUri>https://*****/b2c/IEF/{Culture:RFC5646}/selfasserted.html</LoadUri> <RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:1.1.0</DataUri>
<Metadata>
<Item Key="DisplayName">Local account sign up page</Item>
</Metadata>
</ContentDefinition>
And here is the code for Profile Edit
<ContentDefinition Id="api.selfasserted.profileupdate">
<LoadUri>https://*****/b2c/IEF/{Culture:RFC5646}/updateprofile.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:1.1.0</DataUri>
<Metadata>
<Item Key="DisplayName">Collect information from user page</Item>
</Metadata>
</ContentDefinition>
What I would like is that the {Culture:RFC5646} return the same value for the same user. For example, SignUpSignIn returns "en-us" and ProfileEdit returns "en-us" that way I can maintain one directory instead of two.

Answer 1

I discovered the problem was being caused by the different policies were inheriting different Base Policies. Once I had them inheriting the same Base Policy, it is working as intended.