Localizing a Windows Foundation Workflow service

Question

I'm developing a workflow service which will contain (in the end) a lot of different workflows used to interact with users.

As such, these workflows will need to publish messages to the users, and these messages need to be localized.

I wanted to use RESX files and add an extra parameter when initiating a workflow to set the required culture.

This, however, appeared to fail, as the WF service (especially when it comes to persistance) creates new threads as needed and despite setting the current culture at the start (and working for a bit), in the end my workflow would return to the default culture.

I've also tried setting the Culture parameter of the static classes created by RESX files, but this seems to change the culture across the board for all running workflows (which will likely need to be running in different locales).

Is there any way to tackle this problem?

EDIT:

I know I could use a ResourceManager class, because I can pass the culture I want to use, but then instead of using the strongly typed resource names available in the generated classes I need to use strings - and it's easy to make a mistake.

EDIT 2:

One more thing I forgot to mention - but it ties a bit to the last edit about the ResourceManager. Since there will be a lot of workflows, I'm hoping I can just set up the environment and methodology and let other, slightly less computer-savvy people make these workflows (or, in the very least, help make them). Since communication with the users is crucial, using resources should be as easy as possible.

Answer 1

I've managed to come up with a solution using this blog post. By modifying the T4 template I ended up with non-static resource classes. Next, I've created a serializable wrapper class to instantiate all these resources classes on demand by the workflow.

This is easy to use (a custom workflow action is used to create an instance of the resources), and usage of the resources inside the workflow is very easy: resources.GeneralStrings.Timeout for example.

Answer 2

Try setting up a workflow variable to hold the current culture, and anytime you need to use it for localizing text you could pull the value from the workflow variable. This also tackles the off chance on if your workflow can be suspended, then later on be resumed on a different server on the other side of the world, so it preserved the original culture it was spawned with.