Toolkit controls have literal strings used by their behaviors which show up in the browser to communicate to the user information about the control or get input from them. For example, the Calendar control uses the string “Today” to indicate that the field
right below the dates shows the current date. These interface strings were only in English making it difficult for our users to use the Toolkit controls on websites which needed to be globally sensitive i.e. they had users who were opening their websites in
non-English environments and were unable to understand the messages. For example, a travel booking site’s Spanish version still showed the string “Today” in its calendar when a user in Mexico attempted to use the website. With the localization support, the
controls now use strings translated into that locale’s language. So if your website has the
culture-sensitive settings turned
on, then the Toolkit controls will work out of the box without any extra effort on the part of the website author to build separately for other languages.
Why is localization turned off in Debug?
To make website development easy. When users are developing against the Toolkit and making constant changes to their site and/or to the Toolkit itself to meet their custom requirements, building the Toolkit DLL along with all its resources is an over-head.
At that time, seeing that your changes work without any delay is core since you will be iterating through that process a number of times.
So how do I prevent them from getting into my website’s bin directory?
The resource DLLs are binaries generated from the language resource files, which contain translations for all User Interface strings used by controls in the Toolkit. By referencing the No-source “Release” Toolkit DLL all the language resource binaries are added
to your website’s bin directory during development.
You have some options to work-around this.
Why is Localization turned on in Release?
- You can download the full source version of the Toolkit
- Build a “Debug” Toolkit DLL (which is the default) and reference that.
- Or remove the resources files for any languages you do not wish to localize your website in from the ScriptResources folder of the AjaxControlToolkit project and rebuild a “Release” version of the Toolkit DLL. Reference that DLL in your web-application.
- Or you can download the “No-Source” Toolkit DLL, reference that and delete the unwanted resources files from your website’s bin directory.
To make website deployment easy. Since we would like our users to take advantage of this feature without any extra effort, we have turned Localization on in the “Release” version of the Toolkit so that when you deploy your site, it is automatically enabled.
If the website is only deployed for users that will be in the English locale this configuration will be seamless for them and they should see no difference whatsoever.
So what if I do want the language support when I eventually deploy the site?
When you are developing using the Toolkit DLL it makes sense to have the source version of the Toolkit in case you want to browse the code to understand it better or fix up issues in the Toolkit for you. In that case, the default is the Toolkit debug DLL is
used and it does not add the handful of resource files to your bin folder. However, once you think your application is ready to go, you can build a release Toolkit DLL, reference that and publish your site.
It is a good idea to take advantage of this feature which is built into the Toolkit DLL. We gave this a lot of thought and considered what would be the best way to strike a balance where our users could pick up this feature easily but also have an agile development
experience. Having localization turned on is the right thing to do when users publish their sites but unnecessary during development.