Last post Dec 13, 2008 04:48 PM by rickoshay
Jul 15, 2005 02:09 AM|Eric78|LINK
Jul 15, 2005 10:28 AM|lucdlucd|LINK
i went exactly the same way, and adapted the project found here:
(using custom xml fils to store localized ressources), to have it using ressources located in a sql database...
I also coded an utilisty to manage ressources...
If you want, i can send it to you (as is, with no support of course)
Luc (lucd @ swing . be)
Aug 01, 2005 10:02 AM|bruh_man|LINK
Aug 01, 2005 10:32 AM|lucdlucd|LINK
drop me an email at lucd at swing dot be, i'll send you the thing...
Apr 22, 2006 12:37 PM|lucdlucd|LINK
If anybody interested in, here is it
Apr 26, 2006 12:48 PM|abadincrotch|LINK
Jun 25, 2006 08:30 AM|lucdlucd|LINK
Moved the file there : http://www.inzenet.com/Asp.Net/Default.Aspx
Dec 13, 2008 04:48 PM|rickoshay|LINK
The reason translations are stored in resource files is that .NET comes pre-packaged with a solution that fits the vast majority of needs (a wholly justifiable criterion) but it is not appropriate or practical in many cases. You could implement your own
"provider" but of course they don't make that obvious or easy. If you change the default resource XML the application reloads. Know any commercial apps that would be acceptable for? Besides, who says all of your multi-language data is static? Using a simple
set of dictionaries stored anywhere you (e.g., the database) with simple keys, makes a lot more sense. What you could hard-code are formatting rules for a given locale.
A side note is the term "culture" which replaces the not-invented-here term "locale". Culture is independent of language in that mid-town Manhattan customers get the same "culture" as the Amish. Keep in mind that text translation is part of the UI culture
(not surprising) whereas formatting rules (very much a UI concern) are not. What's important is that there are two settings, not that the names don't make any sense.