I am developing a new web application from scratch. I need to provide multi-language support in my website. Which enable users from different regions of the world to see each web page in their own language.
Since, i am new to this field so i don't know how to achieve this. One possible way is to make each single page multiple times for each different language :(
But i am not will to do so, because it increases the development and maintenance time.
Secondly, what to do with the database, do i need to make some considerations while designing database?
I will develop this site using ASP.Net with C# and use MS SQL server as backend database
You certainly don't want to create separate pages for each language.
ASP.NET is quite well geared towards multiple-languages within one page - with the use of resource files:
An effective way to create localized
Web pages is to use resources for your
page's text and controls based on the
user's language and culture. By using
properties placed in resource objects,
ASP.NET can select the correct
property at run time according to the
user's language and culture.
Using resource files can be a bit of a nightmare for large sites, you may want to check this database resource provider out, although you would have to edit resources from the database as the visual studio resource editor only works with file-based resources.
Implementing a database resource provider
Related
Technology: ASP.NET 4.0, C#, forms/mvc
I am a .NET web designer and I wish to create a modular based website for people, similar to what DNN does (but I want to create my own cut down version).
The idea is that I create a base website that can 'activate' features which the client needs (and has paid for). These features may be used by many clients which require frequent future updates for all clients (so I wish to keep upgrade time down to a minimum).
For example, I upload the base web application using web deploy and it sets up the core database tables/views/SPs in the process.
Then I login into the website as developer and activate the out of the box features that I wish to permit the user to take advantage of.
The only way I can think of currently is via user control, resources etc..
But I need a little of your experience and advice over what the possibilities / dangers are....
e.g. images for an application e.g. blog, that I have activated for a client - how do I reference those images
e.g. Can user controls be dynamically added to a web application (which is pre-compiled unlike a website - it must be a web application since I am using web deploy).
e.g. Modification of web.config to add additional routing (doesn't matter if app has to go down to do this).
The idea is that I can upgrade websites features en-mass, rather than manually enhancing each individual website which given a certain amount of clients would result in an awful amount of time lost.
I do not have access to sharepoint (nor do I intend to).
Any advice on how to automate modularity completely via a front end in asp.net would be superb!
My main problem is how to reference files and resources outside of the websites directory and without using virtual directories (ideally - but open to suggestions).
Thanks,
Dan.
I would suggest that your idea sounds like an ideal scenario for WebParts. There are lots of resources on how to go about building a WebPart management structure from scratch. Then, in terms of your 'bulk update' facility, it would simply be a case of tweaking database entries that are used to configure which web parts a user sees.
I'd be interested to know what you decide to do.
Best
Ian
Try a Multi-Tenancy Architecture as you can find some good info here :
http://codeofrob.com/category/10.aspx
http://weblogs.asp.net/zowens/search.aspx?q=Multi-tenant+ASP.NET+MVC+%E2%80%93&o=Relevance
My new assignment at work is to create a second version of our existing web application. Currently, our application supports only full time brokers, but now we our launching a second site specifically for part time brokers.
The new site will be almost identical to our existing site with the following exceptions:
It will have it's own branding.
A couple of the user controls used for displaying information will be different (but none of the pages will be different).
Our existing users should not have access to the new site and vice versa.
It needs to be easy to test both versions of the website from within Visual Studio easily.
We want to reuse as much our existing code as possible.
I have 2 weeks to do this.
I'm hoping that this is a common scenario and someone out there has some advice for how to accomplish this.
I really, really don't recommend branching projects or other routes which involve copying what is essentially identical code with the exception of branding and authorization. It will certainly be easier in the short run but, as you said, will become a nightmare very quickly trying to maintain almost-identical code bases.
Your pages can make the decision on what controls to show based who is logged in or even set globally to indicate this is the part-time broker version of the application. You could have a set of views and light logic to handle part time vs. full time brokers. Since the sites are deployed separately, a config setting would be straightforward. If you have other versions of the same site, you may have to give this some thought to ensure it would scale with your other variations.
I would even use the same database as long as you can separate the data appropriate using claims-based (preferred) or role-based authorization or similar.
All this said, there does not seem to be any great reason why you'd want to deviate from using the same code base.
I would create a branch of your code and then work against that. This is of course assuming that you are using version control. You are aren't you?
My first thought would be to
copy the entire source code to another IIS website
script the database over to another database (fresh start for new website)
make necessary adjustments to usercontrols and branding
roll out the new site (as Beta)
In Visual Studio, you can create a new project inside the same solution so that you have access to both projects at the same time.
If you're using Version Control... create a branch, and start customizing from there.
what this will do for you is give definitive separation between the two sites... no users have access across sites, all future customizations will be on a per-site basis, etc.
While I really like the idea CaptainTom posted another solution would be to break off the display layer of your application from the rest of the logic and create a new project that implements the new user experience while sharing the rest of the code
i.e. a FillTimeBrokers project and a PartTimeBrokers project with both implementing their logic from a common Brokers project.
in some projects (web application projects) I'm using global resource files. (Stored in the App_GlobalResources folder)
pro:
Really easy to use: e.g. in the markup
Property="<%$ Resources:FILENAME, KEY %>"
con:
- As far as I know, I can't change the content of the resources on the fly. So if a customer is calling and tells me to change a string in the french implementation, I need to deploy a new binary. While using SessionMode="InProc" that might lead to undesired behaviour, like session loss etc.
I'd rather change a line in an XML file, to ensure maximum uptime of the application. I think It would be possible to write one's own localization class, that implements an XML file as underlying datasource (using caching etc.). So the question is, is there any upside in doing so?
Can anybody tell me more pros or cons for using global resource files? (And I'm still listening to suggestions to change resource files in a running web application ;) )
So what benefits do I have by using global resources?
Edit: I'd like to stick to "build-in" solutions in Visual Studio or the .net framework, rather than using a (unknown) 3rd party library.
It's provider model, so you can change the data source. For instance, you can store the resource on the database which is better for data driven applications. Because, you can edit, cache, install and update them simply. Visit here.
Global resources allow to localize your web application. You can have global resource per language you need to support and you will not have to duplicate aspx files. It will also allow users to switch to the language they wish at runtime.
See here:
Walkthrough: Using Resources for Localization with ASP.NET
ASP.NET Web Page Resources Overview
Is it ok to roll your own localization framework? I would be ok using the default .NET localization behavior (i.e., putting text in resource files named a certain way in the assembly), except that we have localized images and text that need to be rendered in DirectX in addition to WinForms and WPF.
I could put form-specific strings in one place and other strings somewhere else, but I think that it makes more sense to keep everything in one place, not to mention it will help to avoid duplicates (for domain values like Yes/No, etc.). It's also possible we may be moving this tool to another platform in the future, so it would be nice to have all the localization information in one platform-agnostic area.
I realize this is a little subjective, but I'm looking for a best practice here...I've worked on projects that take both approaches. Any thoughts?
I have developed systems in which localisation is implemented via database-stored data and metadata. If your app is already making intense use of a fast database backend, you could create a database-backed localisation layer and use it to store localised information, including textual and non-textual data. It has worked great for us in a few ocasions.
Edit. The details won't fit in here, but basically we mirrored the logic of the key/value resource manager that the Windows API or .NET use. We extended that by allowing resources to be grouped into groups, which can be nested arbitrarily. Resource names can be given as, for example, "ClientManagement.MainForm.StatusBar.ReadyMsg", meaning the ready message text to display on the status bar of the main form in the client management user interface. On app startup, a locale setting is read from a config file and a resource manager initialised with it; all the subsequent calls to the resource manager will be using such a locale setting until explicitly changed. We also built an administrative user interface that allowed us to edit the resources stored in the database, and even add new languages. A final comment: data to be localised is not only labels and icons on screen. Option values in combo boxes, for example, also need to be localised.
We implemented a localization using DB backend. We were able to create a great resource editor which allows "translator" end users to dynamically update translations (cannot do that with a resx!). We were also able to support an approval process and group translations by module such that an entire module could be approved for use in a language, or not.
We also decided to implement the localization provider for Asp.Net, which basically does 'automatic' localization with no code by the developer. This was actually the only difficult part of the project as the interface is not well documented. It was hard to debug because it actually runs within Visual Studio host process. We used a web service to decouple the implementation which greatly simplified things. Another good thing is that the translations are automatically cached so the DB is not working as hard. A bad thing is that when your translation service/back end is down and if you do not precompile your asp.net web site, when the user launches a 'new' page, the compiler might decided NOT to translate the page. This behaviour remains (even after the translation service starts up again) until you force a recompile of the site.
I'm looking into using Umbraco for my site and so far I'm loving it.
One big question that I have is how can I version control an Umbraco site as a lot of the data is in the database?
How do you setup a test/dev environment and deploy to production in a streamlined way?
Today (without Umbraco) I used SVN. with different copies of the database for test and production.
The site I building is basically a personal ads site with a complete backend. Would it make sence to keep umbraco tables in a sepparate database and keep my business data in another? (accessed by bunch of user controls)
This is a common hurdle when starting to work with Umbraco and the answer is to use what works for you.
However there have been many discussions on Umbraco forums about this very thing, take a look here:
http://our.umbraco.org/forum/core/general/3619-Source-control-and-multiple-developers
http://our.umbraco.org/forum/getting-started/installing-umbraco/2918-Update-an-Umbraco-website?p=0#comment11311
The key thing to consider is the delineation of content and code. Most code in umbraco is stored externally to the DB and as such can be stored in subversion or any other source control platform. For example, templates, XSLT, CSS, XSLT extensions etc are all stored on the file system.
Page content and site structure are stored in the DB.
There are some grey areas, most notably the dictionary which can contain all sorts of things as well as content.
The way we work with Umbraco is as follows:
We have a separate Visual Studio Web Project which contains folders for templates, XSLT, CSS, event handlers, user controls etc. This is stored in SVN. Then on build of this project the files are copied over or compiled and copied over to our test/dev server instance of the umbraco site.
Once the changes are approved we just copy the files up.
If you need to sync the content between Umbraco instances you can either use Umbraco Pro (which includes a component called Courier, which is precisely for this purpose) or back up your live DB and restore into your dev environment when needed (or even use replication).
We mostly try and avoid editing content in the test/dev environment as this is where merging the content back up to the live site can get tricky. However sometimes this is unavoidable. We also try and avoid editing templates etc through the Umbraco interface.
The answer to your final question, "should I store my business data in another DB", is rather tricky as it depends very much on what you are going to do with the data. If it is content that would be best stored in the CMS store it in the CMS, however if it's heavily relational data that doesn't really fit in a CMS then store it separately.
We are undertaking a project currently where data is stored in an external DB and we have integrated an application directly into the Umbraco backend. This was a non-trivial task (although just grabbing some data via user controls is easy) and you should consider carefully the level of effort required to store your data externally vs the inbuilt functionality of the CMS and the budget/time you have to play with.
If you want to use the visual studio template we do then you can download it from our website.
I know this has already been answered but I just wanted to highlight the fact that a lot of headway has been made with regards to content and code synchronizing. For example - uSync and uSiteBuilder are both great looking packages that allow CMS content such as document types and data types to be controlled using code, and therefore version controlled. They are fairly straightforward to use, although of course please do take backups before using these. Media is usually backed up using something like Export Media although usually it is not a good idea to have your media folder in SVN from its default location. Instead put it in its own branch and host it in IIS as a virtual directory. This way your media is independent of the code.
There is a long way to go with most modern CMS' to have solutions that work well with version control, although there are many things under way. Umbraco is a great CMS and has a huge community.