Mar 12, 2006 03:59 PM|rmprimo|LINK
terrific and succinct commnet on the size of it!
This is by far the most popular question in this forum.
I started with resource files and found very early on that they were a nightmare to manage.
If Microsoft had been bold enough to cut the resx editor from the suite and say: 'We do not provide a resx or translation tool(which is really the case). Get or build your own.', all would have been well.
as for utilizing those translations on the site, i load the set i need from sql on demand based on the users preferred culture. each set is reasonably small so this doesnt present a performance penalty. once a set is loaded, i cache
it so it wont get reloaded every time the page is hit.
if youd rather use the compiled resource files, you could still run a utility against the sql database to "create" the necessary data for the resource files. this gives you the admin capabilities of a sql database while still allowing
you to choose your localization mechanism.
There is one architecture advantage of this combined design-time db, runtime compiled approach. More overhead is in the app than the central db. Just drop them dlls in as many webservers as you want.
All scenarios mentioned here use a db for management. They do not have to be at odds with each other though, as either-or.
1.Run a site for a while with pure db localization. Easy to edit and tweak translations without recompiling. Keep some log of the edits.
2.When that change log becomes pretty static, ie the site is pretty stable from translation point of view, no reason why you couldn't lock them in now.
Run the utility to generate the resx from the db, build to compile them into .rersources and redeploy with sat assemblies.