Problem with changing strings using SR.SetCustomString

Vernon,

That is correct. Resource strings MUST be modified before any UI is loaded. If you change strings after that, then some strings may update while others will not. This is because some resource strings are used in static initializers and thus do not pick up your updates made after they are initialized. Therefore we recommend you only set custom strings in your application's startup code before any UI loads.

Hi,

This is a serious limitation which should be made clear in the documentation about the string customization. Your recommendation is not really a recommendation it is a requirement if the UI is going to be localized.

One design goal of our application is to support the runtime switching of the UI language (i.e. dynamically switching the localised strings). Are you saying there is no way to achieve this with your product?

Thanks,

Vernon

Hi Vernon,

Actually if you read the "Customizing String Resources" topic there is a bolded "Important Note" that reads:

Quote:
"Any string resource customizations should be performed at application startup such as in Application.OnStartup, before any UI or controls have been referenced. This must be done since some string resources are used by static class initializers. Therefore your customizations may not be picked up if not set immediately upon application startup before UI classes are referenced."

Since some string resources are set in static dependency property constructors, they will not be picked up until the app is restarted.

Hi,

My apologies for missing the warning but for the record we did the original localization work with version 4.5 where the warning in the help (although still there and quite clear) is only a "Note" and not an "Important Note" and much less emphatic:

Quote:

Any string resource customizations should be performed at application startup, before any controls have been created.

Clearly you have revised the seriousness of the note recognizing that this is a potential problem, however, even with your new "Important Note" you still say should when in reality you mean must if the majority of string customizations are going to have any effect.

Putting all this aside, you still have not answered the more important question in my original response:

Quote:

One design goal of our application is to support the runtime switching of the UI language (i.e. dynamically switching the localised strings). Are you saying there is no way to achieve this with your product?

Do you have any suggestions as to how we might get the run time language switching or is this impossible with your current design?

Thanks,

Vernon

Hi Vernon,

This question had come up in the past, which is why we added more detail to the message in more recent builds since v4.5.

Sorry I thought I answered your question at the end of my previous post. Runtime switching will not be possible because some static dependency property constructors use the string resources and those are only executed once. Some other areas that use string resources will be more dynamic and will pick up changes. But it is things like the static areas that won't. For instance, here is some code for registering a depedency property in ribbon: Note that the custom strings are pulled into the FrameworkPropertyMetadata, which is only loaded one time. That is why string resources must be set up in your application startup code, prior to UI being loaded.

There are other places where string resources may be set in XAML Styles/Templates for controls too. And run-time changes to those string resouces (after initial app startup) wouldn't be reflected in the UI either unless the control Styles are reapplied.