This is by far the most popular question in this forum.
mbanavige
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.
mbanavige
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.
I'd add that in order not to have to rework the countless other goodies of asp.net that depend on or work with localization, it is best to wrap that translation db DAL into a custom resource provider, and get completely transparent drop-in replacement of the
compiled resources mechanism.
mbanavige
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.
I wrote a design time utility just like that. The resx schema is so simple, I wonder if its even worth publishing.
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.
I am actually considering doing both:
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.
Member
22 Points
700 Posts
Re: Which better resource files or database
Mar 12, 2006 03:59 PM|rmprimo|LINK
mbanavige,
terrific and succinct commnet on the size of it!
This is by far the most popular question in this forum.
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.
I'd add that in order not to have to rework the countless other goodies of asp.net that depend on or work with localization, it is best to wrap that translation db DAL into a custom resource provider, and get completely transparent drop-in replacement of the compiled resources mechanism. I wrote a design time utility just like that. The resx schema is so simple, I wonder if its even worth publishing.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.
I am actually considering doing both: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.
Rob