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
Related
This question is about the performance
I am working on MVC4 and I want to support multi-language views.
I am using one resourse file for each language like this:
Multi.resx For English as default
Multi.ar.resx for Arabic
Multi.fr.resx for Frensh
and after specifying the culture, I do this in my views
#Multi.Name
However, I make breakpoints to check the value of #Multi and really it contains all the keys in my resources. Imagine all of them :P
My question is: would it perform better if I used a resource file for each view? Or will all the resources be loaded when I run my application even if I use multiple resource files for each view?
I am really not good at english, if you didn't understand my question, just ask me to clarify.
I know this is old thread, but I am also looking for the answer. Was single (and huge resource) file will effect the performance?.
After researching, I found this link and I thought to share with you (in case you are still looking).
Well, the short answer is NO, it will NOT affect the performance. However, it may cause problem when working in large team (where each of the programmer requires to modify the same resource file) and it can be troublesome to merge the changes.
Here is the guideline from MSDN:
Choosing Between Global and Local Resource Files
You can use any combination of global and local resource files in the Web application. Generally, you add resources to a global resource file when you want to share the resources between pages. Resources in global resource files are also strongly typed for when you want to access the files programmatically.
However, global resource files can become large, if you store all localized resources in them. Global resource files can also be more difficult to manage, if more than one developer is working on different pages but in a single resource file.
Local resource files make it easier to manage resources for a single ASP.NET Web page. But you cannot share resources between pages. Additionally, you might create lots of local resource files, if you have many pages that must be localized into many languages. If sites are large with many folders and languages, local resources can quickly expand the number of assemblies in the application domain.
When you make a change to a default resource file, either local or global, ASP.NET recompiles the resources and restarts the ASP.NET application. This can affect the overall performance of your site. If you add satellite resource files, it does not cause a recompilation of resources, but the ASP.NET application will restart.
I hope this can help someone who seeking the same answer.
Cheers,
Sam
A solution to your problem is described in this question (answer actually): Split Large Resource File into multiple files physically while compiler treat it as one
Feature flags are something I often use but never really gave much thought about it until this new project I'm working on started.
I usually implement it with lots of keys in my web.config file but this approach has two major drawbacks:
When changing a value inside web.config the application pool is restarted - This can be a problem in a heavy access environment
Having too many keys in the web.config file is confusing and can get pretty messy
What's the best way to overcome these problems?
I would suggest using IoC to abstract away the implementation of your feature flags - all your code needs to access is something along the lines of IFeatures.IsEnabled("FeatureA"). Once you've done this, you can choose the most sensible implementation - some suggestions below:
web.config implementation (compatible with what you have now)
Database implementation (with cached values, possibly using SqlDependency if you want to work on a web farm)
Separate configuration file implementation (cached, but using a FileSystemWatcher to check for changes to the config file and load them without needing to restart the app pool). This allows for the case when you need features defined before you need your DB.
You don't have to store feature flags in web.config.
An option is to store them in a database - this has the added benefit of working well in a web farm.
Note that with feature flags, once you are in a position that a feature will be either permanently on or off (say when transitioning from widgetA to widgetB, and you will no longer need any widgetA code), you should be removing the feature and associated flag. This will help with managing the feature set.
If you want add feature flags to your C# applications I would not recommend creating your own feature flag solution but rather to use one of the several feature-flag-as-a-service providers which are out there that can directly integrate with C# right out of the box.
One such solution is Floodgate which has an SDK for .Net which you can install and be up and running with using feature flags in your application in next to no time.
Disclaimer, my name is Eugene and I'm the founder of Floodgate. That being said my advice is the same no matter what feature flag provider you decide to use.
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
I am looking for the best solution to make it easy to add new languages to an asp.net website without deploying/building the existing code base.
From what I have researched, it seems that you can compile resource files on the fly into Satellite assemblies but I am uncertain how to make the application use these DLL's once generated?
The other option I have seen is to store the translations in the Database, and write a custom ResourceProvider so that the built-in localization methods can be used, whilst abstracting the actual implementation (in this case a database).
Either way, the front end for this site will be the same (meta:resourcekey for the controls etc).
But I am struggling on deciding which approach will be the easiest to upkeep. For example, does publishing a new Satellite Assembly restart the Application Pool or does everything tick over nicely?
EDIT
The translations will be provided by a 3rd party API so human maintenance quality is not important. I thought I would add this due to the answers received.
With Asp.Net (currently) you do not have to compile by your own, you can simply deploy resx files (to App_LocalResources or App_GlobalResources folder) and Asp.Net will take care of compiling them into Satellite Assemblies. That's cool.
With Database approach, you are risking the problems with synchronization: how will you know if given resource string is translated? Also, correcting them is not very easy (for Translators/Localization Engineers). And you would need to prepare "install" script anyway. If that is what you are going to give to translators, good luck. You would face plenty of overtranslations and you would have to correct them (manually?).
Resx files (being simple XML) are a bit easier to validate (it is either valid XML in terms of given XSD or it is not). Besides, it is standard technology, you won't need to implement anything by yourself. That is why, I would recommend it.
EDIT
Another issue with Database-driven resources could be character encoding. You would need to create your own translation kit. My experience is, the result might be in several different encodings. Especially, if you want to use plain text file. On the other hand, default encoding of XML files is UTF-8...
RESX
Having around 30+ languages in mit Windows Forms and Web Forms application (this one, if I'm allowed to place a link), I finally had most success with simple RESX files in App_LocalResources.
What I discovered though was that the compilation was extremly slow in VS.NET, so did a slightly modified approach:
Have only English RESX files in the VS.NET solution.
Have a shadow structure of the website with only the App_LocalResources for all languages, including English in a separate folder, not visible to VS.NET.
Write a simple CMD script to copy the real English resources to the separate folder.
Use my free tool Zeta Resource Editor to actually translate inside the separate folder.
Have a publish script that copies the real web files (like ASPX, ASAX, MASTER, etc.) to the website and also copy the resources to the websites.
This approach makes compilation really fast and still allows me to keep compilation and translations separated.
The drawback is that the first call of the live web application compiles rather long, until now, I figures no way to speed this up/precompile (although I do believe that this is possible).
Database
I also did some projects with localization in database and custom <%#...%> blocks to load the languages.
Today, I would vote against this as it is non-standard. Although it would be probably just as fast to compile, no matter whether 1 or 50 languages are involved.
3rd Party Tools
You also could fetch a commercial product to do the translation, if I could afford, I would have done this most likely, too.
Just my two cent...
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.