I think you can rely heavily on the resource framework provided by .NET with a few modifications to make it more appropriate for large projects, namely to build and maintain resources independently of the application and to eliminate the generated properties that refer to each resource by name. If there are other goals appropriate for large project localization that aren't addressed below, please describe them so I can consider them too.
- Create a stand-alone project to represent your resources that can be loaded as a separate DLL.
- Add a "Resources" file to your project by selecting the link on the Resources tab of the project properties: "This project does not contain a default resources file. Click here to create one."
- Add another resource with the same root name to represent another language, for example "Resource.de.resx" for German. (Visual Studio apparently uses the filename to determine the language that the resource file represents). Move it to the same directory/folder as the default Resources file. (Repeat for every language.)
- In the properties of the Resources.resx file, delete "ResXFileCodeGenerator" from the Custom Tool property to prevent default code generation in the Application's "Properties" namespace. (Repeat for every language.)
Explicitly/manually declare your own resource manager that loads the newly created resources with a line like:
static System.Resources.ResourceManager resourceMan =
new System.Resources.ResourceManager(
"LocalizeDemo.Properties.Resources", typeof(Resources).Assembly);
Implement a file that can be generated that contains a list of all the resources you can refer to (see figure 1)
Implement a function to retrieve and format strings (see figure 2).
Now you have enough that you can refer to translated strings from any number of applications (see figure 3).
Use System.Resources.ResXResourceWriter (from System.Windows.Forms.dll) or System.Resources.ResourceWriter (System.dll) to generate the resources instead of having the Resx files be your primary source. In our project, we have an SQL database that defines all of our strings in each language and part of our build process generates all the Resx files before building the resources project.
Now that you can generate your Resx files from any format, you can use any format you want (in our case an SQL database, which we export to and import from Excel spreadsheets) to provide files to send out to translators.
Also notice that the translated resources are building as satellite DLLs. You could conceivably build each language independently with the right command line tools. If that is part of your question (how to do that) let me know. But for the moment, I'll assume you know about that since you already mentioned custom build steps.
Figure 1 - enum identifying all available resources:
namespace MyResources
{
public enum StrId
{
Street
....
}
}
Figure 2 - Code to load and return formatted resource strings:
namespace MyResources
{
public class Resources
{
static System.Resources.ResourceManager resourceMan =
new System.Resources.ResourceManager("MyResources.Properties.Resources",
typeof(Resources).Assembly);
public static string GetString(StrId name,
System.Globalization.CultureInfo culture = null, params string[] substitutions)
{
if (culture == null) culture = System.Threading.Thread.CurrentThread.CurrentUICulture;
string format = resourceMan.GetString(name.ToString(), culture);
if (format != null)
{
return string.Format(format, substitutions);
}
return name.ToString();
}
}
}
Figure 3 - accessing resources:
using MyResources;
namespace LocalizationDemo
{
class Program
{
static void Main(string[] args)
{
System.Threading.Thread.CurrentThread.CurrentUICulture =
new System.Globalization.CultureInfo("de-DE");
Console.WriteLine(Resources.GetString(StrId.Street));
}
}
}
