Structuring Resource Files

Question

In .NET we've got Resource files which are great for allowing providing translations across your application.

In the past I've seen these resource files grow into monolithic unmaintainable lists of words and phrases. What is the best way to avoid this?

• A single resource file for your entire application? It's easy to translate, has very few duplicates but grows to an incredible size
• A resource file per project, this has the benefit of keeping resources and code together, breaks down the file but creates a much higher chance of duplicates between the files.
• Many small files. For example a resource file per project in the BLL/Dal and one per Area/View in the UI (let's assume MVC).

Having struggled to maintain massive resource files in the past I'm tempted by the third option. To create a single per controller/logical separation in the UI level. Although this may cost more in translation (and lead to more duplicates) it will be much easier to maintain.

Is there another or recommended approach to handling resource files in larger applications?

Answer 1

I'd use one resourcefile per project (assembly). That way the assembly can still be reused without depending on the application and it has the added advantage that your resource files are smaller. The downside is that it might have some duplications for texts like "Yes" and "No", although you could opt to put these in a shared resource file (which personally I wouldn't do). You could also reference other assemblies if an assembly depends on those.