There is a nice big space on page 27 of the “Internationalizing and Localizing Rhythmyx” manual, after the two sentences that are the only contents of that page, which could be filled with important information we had to discover via technical support, such as that the en-us locale is the permanent default. It cannot be changed, and should not be deleted or deactivated. The first time a user logs in to the 6.5.2 Content Explorer, their language is set to en-us, even if the only enabled locale is a different one that you have created. And when they log out, their preferences are stored in a persisted property that is tied to the en-us locale.
Correct. Rhythmyx does not provide a way to configure the default Locale.
It cannot be changed, and should not be deleted or deactivated.
I’m not sure what change you would want to make. You can change the Label and Description of any Locale, and enable or disable it. A Locale really does not have any more data than that.
We have not formally tested the effect of disabling the default Locale, so we cannot state with certainty whether this action is recommended or contraindicated. Until then, the safest course is not to disable it.
The first time a user logs in to the 6.5.2 Content Explorer, their language is set to en-us, even if the only enabled locale is a different one that you have created.
This behavior is a bug. It has been logged. The ID is RX-13987.
And when they log out, their preferences are stored in a persisted property that is tied to the en-us locale.
Thanks for the confirmation of bugs, and the reference numbers. I’ll email tech support to request we be added to the notification list for those.
When I said that the en-us locale “cannot be changed” I was attempting to clarify what I meant by describing it as “the permanent default” - i.e. that you cannot set up another locale to be the default.
Until this week, we had been using our systems for at least six months with the en-us locale disabled, yet apparently still the default. In that time we’ve had dozens of problems, but it is too early to tell whether disabling the default locale had any part in causing them. Tech support probably had no idea we had disabled it, and we had no reason to think doing so was inadvisable. Which is why adding more detail on this issue to the documentation would be a good idea.
“Just document it” is not necessarily the right answer. As I said, we have not tested this configuration, so we don’t know whether disabling the default Locale will work, or whether it might cause other functionality to fail. If it does work, we don’t want to take that option away from you. If it does cause other features to fail, it’s possible that it will reveal a more critical bug that we want to fix, and in the end, the configuration will be supported.
In the end, we want to be sure we put the right information in the documentation. At this point, we have not determined what the right information is.