I made a multilingual site using resource files (ASP.NET MVC 2). Now I want to use the database in order to make a page where the user can input the information that will be published on the site. Does this mean that I can no longer use resource files? On the way to keep multilingualism using database?
I'm not 100% sure if I get your question, but from a technical and practical point of view you can mix content coming from Resource files and content coming from a database.
For all you static texts (messages, buttons etc) you will use your resources, and for dynamic texts (texts that [often] change) you will use your database.
It is also possible to create your own resource provider, that instead of taking the resources out of a file, it will take it out of a database.
You should try a custom resource provider. You can then choose what resources come from which sources.
The following urls might be of use:
Extending the ASP.NET 2.0
Resource-Provider Model
Creating
a Data Driven ASP.NET Localization
Resource Provider and Editor
For static content you can use resource files but if you need to modify data and you want to translate data in different languages you should use data base. using data base is more flexible.
Related
I m new to Umbraco, I have watched Umbraco.tv videos and want to use Umbraco in a project as a cms for managing and editing content. I am highly thankful for your guidance, time and for your thoughts on 3 questions:
How a Umbraco based data driven proejct should be architecutured ? For custom database tables do you use a separate database or same Umbraco database ?
How you work with custom data (non content) ? Do you make everything a document type, even if it is data which you are not going to create content of, for example a simple form submitted data ?
For DAL what technology or ORM you use ? Does Umbraco provide any API for saving simple data which is not a content or document type ?
Thank you so much once again.
1 The architecture question is important but it also has be considered against how complex the project needs to be.
I would usually recommend a separate database for non-Umbraco data since this keeps everything nicely independent and manageable especially as projects grow. It also means that CMS-specific data (i.e. content) can be kept separately from none-CMS data, e.g. user registrations.
However, if the project is small and isn't likely to grow, keep it simple. Use the same database and piggy back off Umbraco's implementation of the Petapoco ORM. For example:
ApplicationContext.DatabaseContext.Database.Save(new Thing());
Or
var item = ApplicationContext.DatabaseContext.Database.Single(thingId);
2 For custom data, again it's a matter of need, maintainability and simplicity. Only use document types for what needs to be and can be stored in the CMS. My personal rule is that if it isn't content or organises content then it doesn't belong in the CMS. For example news and news categories obviously belong in the CMS. However, the comments made on an article have no reason to in the CMS.
3 With regards to DAL, as I have said, Umbraco has an implementation of Petapoco that can be used out of the box. If the project is basic enough, just use that. There is little point in using anything else unless you need some separation and/or some additional grunt in which case I would recommend using NHibernate or EF.
In addition to the points above,
Use NuGet;
Use the MVC mode of Umbraco, as it will provide you with substantially more flexibility. Check out the Hybrid Framework as it provides a very good start point for a robust and flexible project architecture;
http://www.youtube.com/watch?v=0PtzyrEFG7I.
You always need a doctype in Umbraco, even if a page doesn't offer any WYSIWYG type editability
I would recommend using a Service Oriented Architecture, and the .dlls you drop into Umbraco can call the service. You can then deploy this service and have full control over how you do data access. Choose whatever method you want. Most modern sites use an ORM and it doesn't matter which, although nHIbernate and Entity Framework are the favourites. Don't be frightened to mix and match a more direct form of data access though as it can give you more control, especially in situations where performance optimisation of large queries is important.
If you're not familiar with adding custom .NET functionality into Umbraco, Trying out adding .NET user controls into Umbraco will give you a good start, and to help you to understand how you can utilise your own .dlls in Umbraco:
http://umbraco.com/help-and-support/video-tutorials/introduction-to-umbraco/developer-introduction/using-net-user-controls.aspx
Anything custom I put in the same database as my Umbraco installation, but everything in custom tables. I don't touch the Umbraco tabes, I would not want to affect my future version updates.
Form submitted data I store in my own custom tables, I avoid creating content nodes with those, it's often tricky and doesn't give me the flexebility I often need. What I do instead is create an "Admin" document type, that is behind login (hard coded access, but easy to hook up to Umbraco users / members if wanted) and use my own custom UI to display my stored custom data.
I use PetaPoto (http://www.toptensoftware.com/petapoco/), it's a micro ORM that is added through a single file (installation is so easy then), using the same db connection string. Then I create custom models as I need and with with parts of the MVC. I normally stay away from route hijacking and rather use Surface Controllers and ajax calls for almost everything.
Hope this helps!
You can use the database containing the Umbraco tables for tables not used in Umbraco. If there are no hosting problems for you using multiple databases then you can simply link to a second database in the web.config - this would be safer than using the default Umbraco database as Umbraco packages often add database tables & there could be naming conflicts.
Viewing non-Umbraco data (eg from a database) is best done by adding macros that access the data using standard .Net patterns (eg razor scripts, .Net User Controls) & then in Umbraco you add in a reference to the macro in the template (view). You can use multiple templates (views) for any document type; so if you have a document type called 'forms' that contains no data you can use the 'allowed templates' checkboxes to say which view(s) are valid for this document type. When you add a content item you must specify a doc type at the start, but the template (view) can be changed at any time.
If you are storing data any .Net ORM will work with Umbraco (see http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#.NET) I've used Linq to Sql, Subsonic & Dapper before now - but there are lots of options.
Take a look at my example using umbraco within Onion Architecture
https://github.com/afroukh/OnionCMS
I want to convert my existing website which is created in asp.net mvc to a multilingual without resource file.I have a lot of client side content (obtained through ajax in javascript) what is the best possible way?
I wouldn't stray too far from resource files. They're meant to be used for localization, and they're good at it. You may need to template some JSON strings from a resource file, but that'll be faster than a DB lookup, or file read.
For the purpose of localizing client-side content to be displayed to the user, are partial views possible? You'll get the benefit of the typical MVC pipeline (i.e. passing through the localization modules) but also get the content via an Ajax query.
I am currently working on a project that requires Static Text to be configurable(including labels, messages, and validation errors). I was wondering what the best approach would be. The app is being written using ASP.NET MVC and C# 3.5. I need all this static configurable text to be fed to the MVC project from a different project. I thought of using Global Resources, or using an XML file that would be loaded on application start. By the way, this is not about localization, also static text won't be configurable by the end-user.
You could use AppSettings and web.config as James answered. you could also store it in a database, with key value pair structure.
But you also need to get it from the configuration project to the ASP.Net MVC project. I would do it like this:
Create a service interface on the configuration project
use Enterprise Library Caching in the ASP.Net MVC project
Check if the value is cached
If not get it from the configuration and store it in the cache
I would probably make a separate project that contained a series of Resx files, these are pretty easy to work with and give you localization for free. This is where I would start and if you need to edit them on the fly through some admin tool then you could use something like Rick Strahl's data driven provider. This is probably a better approach then trying to come up with your own DB driven design.
I do agree that you probably need to clarify a bit of how and when the text will be editable.
Definitely stay away from the web.config and appsettings unless we are only talking about 1 or 2 lines of text. In general this is not a good idea for many of the reasons others have stated about app restarts and just general config bloat.
I would store it in the AppSettings section in the Web.Config file.
Localization is actually a decent way to handle this--it is solving the same problem, you'd just need to provide a single language file. Downside is that localization bits are not necessarily easily end-user editable. Which drives me to the fact that the real question to answer here is "how user editable is this information going to be?" If the answer is "frequently and easily" then you might want to make some sort of UI Snippets table in your database and handle it accordingly. Another decent option would be to use a custom configuration section and read/write to it using the configuration API. Also leaves open hand-editing XML files if need be.
I would use a XML file with a single load at the application startup
I'm developing a website using ASP.NET MVC. The website should handle multiple languages.
I would like to ask what are the best practices of handling multiple languagues - both for "static" texts and taken from DB. I read some threads about this on stackoverflow but i'm not sure how can I implement in when data from DB are received. I also read this article
Well, if you need to localize your web application then you can't really use any "static" text. The article link you included talks about using resource files. While this does work in ASP.Net MVC it means that everything in your view pages will have to be an ASP.Net Literal control and you have to push ALL of your textual content into the .RES file and not put any of it in your view pages.
If you have a lot of users from different cultures then using the .RES files will be the way to go. If you have the majority of your users all in one language and just a small percentage in a different language then you may be able to take advantage of Microsoft’s translation engine. You just embed some JavaScript in your page and Microsoft will translate the page’s text for you.
There are a number of questions on this site related to how to access RESX files in an ASP.NET MVC application, and best practices of using them.
However after reading (for the first time I might add) the MSDN article on resources I'm left wondering if there are even any advantages of using RESX files since I'm not going to be using server controls. Theres all this talk of 'implicit' and 'explicit' localization but I'm not going to benefit from that with MVC.
Ultimately my application will need string resources for buttons and menu items and also much longer HTML items for longer miscellaneous content. I would like to use a CMS for the longer items becuase I'm pretty sure I don't want to go sticking them into an RESX file.
Are there any compelling reasons to use or not to use ASP.NET resources in a new application. I'm going to assume that any future MVC enhancements or RESX enhancements will work in harmony together, but for now I'm just getting a glorified IDictionary as far as I can see.
Should I proceed with RESX or look elsewhere? Should I even be considering a CMS for the kinds of resources that RESX is designed for?
Any lessons learned would be appreciated.
There are couple of advantages to the RESX infrastructure:
you don't have to load the proper per-language resources. Once the locale of the thread is established, the CLr takes care of finding the appropriate assembly and loading the resources.
it is easy to hand off the locale-specific resources for localizations to third-parties.
there is a default fallback mechanism for non-localized resources.
There is also one particular disadvantage to the RESX approach:
it is hard to support translation model where the users translate your resources for you.
I'd like to elaborate a bit about that last point. Take for example the Facebook translation model. Facebook has fairly simple way for people to provide and vote on translations of various resources. If these are stored in a database, it would be possible to use them after the proper editorial process without rebuilding and redeploying the application. With the RESX model, the resources assemblies will have to be rebuild and redeployed, which could have high enough cost depending on the deployment process.
Thus, before deciding what localization process to use, I would look at the decision of who is going to do the localization and what the deployment process for the localizaed resources would be after the main application is already deployed.
EDIT: I forgot to mention that these considerations are orthogonal to the ASP.NET framework choice (MVC or WebForms).
I'd say "yes", resx files are still a good option for new applications. I don't think ASP.NET MVC in particular changes anything about storing your strings.
What's great about using resources is
they're pretty easy to manage
localizing your site is a much easier task than without resources (and I stress much easier)
you can replace the resource store at any time because resources use the provider model. You can switch out resx files for db entries without changing the implementation of your site.
I recommend resource files for the "site strings" which are different than the large blocks of data you might edit on a frequent basis. So for a full recommendation, I'd say use resource files (resx to start) for buttons, labels, etc, and a CMS for the meaty content.
If you are going to use Resx and not use Server Controls as you are in MVC, why not extend the MVC Helper methods so you can create localised labels and text? Then simply call the text from resource in the helper method.
e.g.
'<%=Html.CultureLabel("ResouceId") %>'
or
'<%=Html.CultureButton("Name","ResouceId", HtmlButtonType.Button) %>'
Just a thought.
Also managing globalisation of a site is MUCH easier with resx for the text.