Localization information can be read from resource files, satellite assemblies, or the database.
The best option storing resources depends on the application type.
Windows Forms applications can use resource files or satellite assemblies. When to use what depends on the user/customer of the application. If it should be possible adding, changing resources for different languages just by using an editor (XML editor), resource files can be a good option. In most cases, satellite assemblies will be the better choice. With satellite assemblies resources are embedded in a binary format within a DLL. This makes the resources not so visible to the user, and faster access is possible.
If the Windows application is not using a database directly, there is no need to think about putting the localization entries into the database.
With Web applications, using resource files is not a good option. The ResourceManager locks resource files, so it is not possible to update them with a running ResourceManager. So the two options left are satellite assemblies, and reading resources from the database. Because with a web application, usually a database is used, reading resources from the database is a perfect option. However, my sample of a resource reader to read resources from a database is just a simple implementation to show how to implement a custom resource reader. Adding caching functionality would be an useful task that can increase performance and scalability.
With web applications we should also differentiate between localized control values and content. If the content is read from the database, so should be the localized content. Localized control values can be read from satellite assemblies.
The Enterprise Localization Toolkit takes an interesting approach to localize web applications. It has some web applications and tools that make it easier to localize controls (not the content), and allows creating satellite assemblies.