Diavolo localization subsystem is now 100% ready. I have to say I'm really happy about this result because now everything is in place and I can really appreciate its strength, thank to .NET framework structure.

As I wrote in my last post, all localization features are supported and can be used but what I find extremely useful is inline (literal) expressions. While Javascript is getting stronger and stronger for advanced UIs, JS code is usually markup-based and in that context .NET developers have two choices: embedding JS scripts or emit them, meaning using server code to emit client-side scripts. The second way makes it easy to support localization and other customization while first one is easier to use and maintain. Diavolo now makes it possible to produce markup like this:

<ul id="sdt_menu" class="sdt_menu">
		<li>
			<a href="/">
				<img src="/images/2.jpg" alt=""/>
				<span class="sdt_active"></span>
				<span class="sdt_wrap">
				<span class="sdt_link">
<asp:Literal ID="Literal1" runat="server" Text="<%$ Resources:system, home >" />                                                                                </span>
					<span class="sdt_descr">Torna alla pagina<br />principale del sito</span>
				</span>
			</a>
		</li>

This is a simple unordered list which can be used to create menus and other elements and to support localization and customization you can simply replace relevant code (for example, menu items or text) with a simple server-side code and leave other stuff intact. At run time, this code:

<asp:Literal ID="Literal1" runat="server" Text="<%$ Resources:system, home%>" />

will simply be replaced by relevant text, using different languages according to user locale. That's exetremely useful per se but you must also consider that things get very juicy when you couple that with administrator's ability to edit keys in a very easy way inside portal itself. Following picture shows a (very basic) localization editor where portal administrators can explore keys for a specific category and locale:

On top of page you will find a list of categories (more about them in a moment) and locales while table shows all defined keys and their values. Single items can be edited and updated by portal administrator or even deleted. Unless they are system keys, the meaning of which I will explain in a moment. Inline editing makes it very easy to change key values and browsing among locales is also very easy. I also plan to add a way to filter items, maybe by specifying part of the key. When you will have tens of keys, even if they will be sorted, you need a quick way to find a specific key or at least a group of them.

Advanced features
Earlier, I mentioned a few things which probably aren't so clear. Let me start by explaining categories. In old, RESX-based context, first item in your key specification was resource filename or assembly name. That is, in "system, home" first term was meant to specify filename or assembly name and secondo one its actualy key. Diavolo has no assembly name nor RESX files but I thought that way to create keys partition was very handy so I decided to support that scheme by creating categories, which have the same task. Their goal is to provide a logical boundary among keys so, for example, system category will probably contain most system-wide keys while a blog category could include all keys related to a blog module or to blogging support. That's very handy.

Also note that Diavolo fully supports local resources, that is resources which are created for specific controls or pages, which were represented by old App_LocalResources folders. It's important to note that part of original specifications is fully supported and basically virtual path to object will become category name when you will use local resources. And, best of all, local resources will be editable as well and that's so handy for module developers !

Finally, we have system keys. While each installation of Diavolo will feature a system category which will group most system-wide, platform-defined keys, developers and administrators can also turn each key into a system key. Those keys need to be considered vital in order to let portal work as expected, maybe because they're used in administration pages or other important areas. Maybe they're just hardcoded in ASPX/ASCX code and, if deleted, compilation would not succeed. Either way, removing such key could be harmful and that's why portal administrators won't be able to remove them. Also, there will be two different functions in code to remove standard and system keys, so developer must be aware about what he/she's doing before doing that.

The good part is portal administrators can promove keys from standard to system. They will be able to edit such key and select specific checkbox to turn them into SKs and that's very useful. Imagine an admin installs a new module which rely on a specific key to be present. Now that key wasn't a SK and could be removed by other modules or maybe another admin who doesn't know such module has been installed. By promoving such key to be a system key, administrators won't be able to delete them by using editor and other modules will need to treat it as a system key in order to remove it and that probably means they will show a warning about it. This will reduce chances that key will be deleted by accident.

Lastly, I wrote that admins won't be able to delete a system key: that's not 100% true. If they use editor to remove one, an error will occurr. If they are 100% sure they want to remove it, they can edit such key and turn it into a non-SK and then they will be able to delete it. Either way, that extra operation will make them aware they are potentially deleting an important key.