I'm wondering about maintenance and performance
The only performance issue you will run into is load time. That's one of the reasons why loading the appropriate resources should be a start-time concern. Typically that is handled by referencing the resources in a
global.asax file (or the backing C# file).
Well, there's a number of things to consider here. With i18n resources, you only have to specify the resources that are different in your language. If the bulk of the resources are going to be the same as the native language resources, then the resources infrastructure handles failing back.
Let's say that
core.resx has all the 3d models, and the default native languages for your app. Let's say your native language (as specified in your project file) is
en. You would have the following:
core.resx -- Defines models and EN messages/errors
core.es.resx -- Only defines ES messages/errors
core.fr.resx -- Only defines FR messages/errors
If the application is run in a Spanish native language machine, then the resource system will only pull the overrides from the
core.es.resx, while delegating to
core.resx for the actual 3d models.
What this means is that your main resource is very large, and that the language specific resource files are much smaller.
There are no "best practices" per se here. A lot of how you split up your resources will be affected by the following:
- How you organize your code
- How your translation provider might want to split up work
Particularly with specialty language needs (like automobile parts), the translation house might have different people who are better versed in different specialty areas. Breaking up the resources to support that process may help speed up the work.
I might recommend at least bundling the resources around the "machine type" in your above scenario. All the necessary terms, labels, and error messages will be closely tied together. When you add a new chassis type, you only have to update one resource bundle. That would make maintenance a bit easier.
In this project, I chose to break things up by how I organized my code. The way I forced load at start up time was by declaring the resource managers in a static initializer. There's no reason in that project why I couldn't have merged them all into one resource bundle. It just made it easier to think about several parallel concepts as they were separate bundles.