Using TranslateX with EPiServer 6 R2

In a recent project, I had to install the TranslateX module into an EPiServer 6R2 site. TranslateX is an open source EPiServer module that allows you to export pages in XLIFF format for translation services. The problem is that the original module was created for EPiServer 4 and has been since updated to work with version 6.0, but I was unable to find any resources or help to get it installed in 6R2 or 7. After some trial and error, I came up with these steps.

  1. Download EPiServer CMS 6.0 from EPiServer World and install it. Don’t worry — even though it’s an older version, it shouldn’t cause any problems with your R2 installation.
  2. Download the install package for the 6.0 version of the module.
  3. Run EPiServer Deployment Center (located at C:\Program Files (x86)\EPiServer\Shared\Install\EPiServerInstall.exe by default).
  4. On the All Actions tab, run Installed Products > EPiServer CMS > Version 6.0.x > Modules > EPiServer.Research.TranslateX.Installer.6.
  5. The default options for the first step of the installer should be fine. On step 2, check the “Show All Sites” check box, and then select the site where you will install TranslateX. (Note: You will receive a compatibility warning when you check the “Show All Sites” check box, but it doesn’t appear to be a problem.)
  6. Finish the installation.

Now, you should have it successfully installed. However, there’s more to do before it’ll work. First, you will need to create a folder for TranslateX to save temporary files, and EPiServer will need write access to the folder. You can name the folder “translationtemp” or something similar.

Open your Web.config file and look in the AppSettings section for a key named “xliffworkpath”. You’ll need to update this value with the location of your “translationtemp” directory.

At this point, you can now create translation projects for your pages by navigating to a page in the CMS and clicking the “Translation” tab. But when you try to run the project (Admin Mode > Admin tab > Scheduled Jobs > Translation scheduler service > Start Manually), you’ll probably notice an error on the “History” tab and you will never receive an e-mail with the translation. That’s because you will need to tell EPiServer which languages are available for translation through an XML file.

In the root folder of your EPiServer installation, there should be a “lang” folder. Create an XML file called “translationlangs.xml” and place it in that folder. Here’s a sample of the content to include in the XML file:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
	<language name="English" id="en">

	<language name="British" id="en-GB">

	<language name="Spanish" id="es">

Make sure to update the XML to fit your own language needs. As long as your mail server is working, you shouldn’t need anything else. If the “History” tab on the translation scheduler service says, “OK,” after starting the service, you’re good to go.

I haven’t tried installing TranslateX in EPiServer 7, but let me know if the steps above were any help.

Simple jQuery Autosubmit Plugin

One issue that I have with ASP.NET is how often it injects inline styles and scripts into your pages. One example is the “AutoPostBack” attribute that you can add to your DropDownList and RadioButtonList server controls. When this attribute is added, an inline “onchange” event handler will be added to your markup along with some other scripts. Ideally, this functionality should be handled in an external JS file, and it’s really not that hard to do.

Here’s a quick jQuery plugin that will accomplish that without having to rely on .NET’s “AutoPostBack” feature.

/// <summary>
/// The parent form of the provided element(s) will be submitted when its/their value changes.
/// </summary>
/// <param name="options.ignore">An ignore option is available (array) to prevent the form from submitting when certain values are chosen. By default, options with an empty string value are ignored.</param>
/// <param name="options.trigger">If trigger is omitted, the parent form will be submitted. Otherwise, a click event will be triggered on the provided jQuery object.</param>
(function(factory) {
	if (typeof define === 'function' && define.amd) {
		// Register as an anonymous module
		define(['jquery'], factory);
	} else {
		// Browser globals
}(function ($) {
	$.fn.autosubmit = function (options) {
		var settings = $.extend({
			'ignore': ['']
		}, options);

		this.change(function () {
			var $this = $(this);

			if ($.inArray($this.val(), settings.ignore) === -1) {
				if (typeof settings.trigger !== 'undefined') {;
				} else {

		return this;

Using the plugin is very easy. Create your DropDownList as usual, but give it a CssClass attribute so you can reference it easily:

<asp:DropDownList ID="myDropDownList" CssClass="auto-drop-down" runat="server">…</asp:DropDownList>

Include jQuery and the plugin file in your page, then write some JS similar to the following:


The plugin also allows you to specify certain values that will not autosubmit when chosen. For example, you may have a drop-down with a “Select an option” choice, in which case, you wouldn’t want to submit the form unless a different choice was made. Here’s how to ignore certain values:

$('.auto-drop-down').autosubmit({'ignore': ['', 'n/a', 'empty']});

One more thing to point out — be sure to include a submit button even if the autosubmit feature makes it unnecessary. If someone isn’t using JavaScript, they should still be able to use the drop-down on your page. Another line of JS for hiding the submit button is trivial:


Tabs vs. Spaces: Why is there a Debate?

Whether to use tabs or spaces when indenting code has been a source of contention among developers for some time. However, in none of these debates have I found a legitimate reason for spaces instead of tabs — at least not when both sides have a firm understanding of how tabs are to be used (i.e. indentation, not alignment).

Advantages of Tabs Over Spaces

So, why do I prefer tabs over spaces? It’s quite simple: there are a huge number of advantages and very, very few reasons to use spaces — namely to work with teams that are stuck in their ways.

1. Fewer Key Strokes

This one should be obvious. Pressing the tab key on the keyboard is only one keystroke. Unless you indent with only one space (which is bad for other reasons), you’re spending more time typing. Now, I hear you saying that almost all modern code software can automatically replace a tab with a certain number of spaces. Let me say that this isn’t a solution; it exacerbates the problem and makes it nearly impossible to insert an actual tab character. It’s just a patch to a problem and misleads people into thinking that white space isn’t important — until they work with someone else’s code, who didn’t use the same number of space characters as the “auto-space” feature in their editor.

2. Easier Keyboard Navigation

Even if your editor does replace tabs with spaces, it usually doesn’t change how the arrow keys navigate through those characters. With tabs, I can use the left/right arrow keys to move back or forward one level of indentation with each key press. This doesn’t work with spaces, and if you’ve only ever used spaces, you probably don’t even realize how inefficient it is.

Many hard-core coders will point out that there are editors such as Vim with very efficient keyboard navigation that doesn’t rely on the arrow keys or that you can use keyboard shortcuts (like ctrl+left arrow) to move through white space, but not everyone uses those editors (or is proficient with them), and shortcuts are often still more complex. Even so, the ability to move from one level of indentation to another is not addressed.

If you’ve worked with spaces your entire career, then you probably think that being able to navigate quickly through levels of indentation is a minor boon. You’ve probably learned to naturally compensate by using your mouse and clicking to place the cursor where you want or some other keyboard combination. However, tab users immediately recognize how painful it is to move through code with spaces. It’s like switching from a two-button mouse to one with only one button — why would anyone do that?

3. Smaller File Sizes

Both space and tab characters take up one byte of space. If you use two spaces to indent, you’re doubling the file size of your documents, and you’re more likely quadrupling the size since many editors default to four spaces per tab.

Most space apologists will claim that code can be minified or compressed in some way, but let’s be realistic. Take a look at the source code of just about any website’s HTML that relies on spaces for indentation, and you’ll find that the vast majority are not compressed. Even when they are, the original source exists somewhere and is taking up disk space. Storage may be cheap, but that’s not a good reason to fill it up.

4. Configurable Indentation Preferences

Suppose I like four spaces per level of indentation, but my colleagues prefer three. We’re eventually going to have to negotiate on one or the other, and if I’ve been using four spaces, then it’s going to be hard to break that habit. This leads to inconsistent, sloppy code. Even if I eventually adopt my team’s standard, what happens when I move to another team or inherit a project from other developers? It also means that any new team member will also have to adopt our version of the acceptable number of spaces.

If you were to use tabs, you wouldn’t have this problem. Each developer can configure their environment to use a specific tab width; whether it be two, four, or even eight spaces. This makes everyone happy. Imagine if you forced everyone to use a specific font size or syntax highlighting. Obviously, these things don’t impact the quality of the code, so why not let everyone customize them to their own personal preference? Why are you being a white space Nazi?

5. Readability

Quick question: How many levels of indentation are there in the line with the //Case 1 comment?

····for (a = 0; a < b; a++) {
········switch (c) {
············case 1:
················// Case 1 (WHAT'S MY INDENTION LEVEL?)
············case 2:
················// Case 2

Did you get four? If so, it’s because you had to read the surrounding code to figure it out. Now, let’s try it again with tabs.

--->for (a = 0; a < b; a++) {
--->--->switch (c) {
--->--->--->case 1:
--->--->--->--->// Case 1 (WHAT'S MY INDENTION LEVEL?)
--->--->--->case 2:
--->--->--->--->// Case 2

See how much easier that was? Each tab is one level of indentation. With spaces, we’re at the mercy of the developer and whether he/she was consistent with the number of spaces. Finding errors with improperly nested code is much easier when tabs are used. You can’t accidentally forget a part of a tab, but you can easily enter three spaces instead of four.

By the way, I purposefully made a mistake in the number of spaces for one of the lines in the first example. Did you catch it? Would you have missed it if I had used tabs?

Why Spaces are Problematic

1. No Consensus on Amount of Identation

We touched on this in briefly in the points above, but it’s important enough to get its own section. No one agrees on how many spaces make up one level of indentation. Standards are important when it comes to code. Just because your team has come to a decision on a set number of spaces per indentation, doesn’t mean that they’re all happy with it, that they’ll all honor it, or that the decision will work on anything other than new, start-from-scratch projects.

With tabs, there’s only one decision to be made: tabs or spaces. With spaces, there’s tabs or spaces, and how many spaces. Given the advantages of tabs outlined above, I don’t see why this should be a hard choice.

2. Not Portable

What do I mean by “not portable?” I mean that if you share your space-indented code with anyone else (e.g. all those online tutorials where you can copy/paste the code), the recipient is going to have to reformat it for his/her environment. People that use spaces instead of tabs think that this is just par for the course, but tab users have a big advantage here — they can use the code as-is. Worst case, they may need to change the indentation level, but they’ll certainly never have to go through each line adding and removing spaces. And don’t say, “editor X handles this fine.” Wait until you have to work in a client’s environment where only Notepad is available.

3. They’re Hard to See

Spaces are a poor fit for indentation simply on the fact that you can’t easily see an individual space character among groups of spaces. How often have you been typing an Office document where you had to do a double-take to see if you had typed two spaces instead of one? Granted, this isn’t as much of a problem with fixed-width fonts, but it’s still a problem.

I absolutely hate it when developers use only one or two spaces for indentation, and it’s not because of bad eye sight. If your HTML or XML is so complex that you need tens of levels of indentation and it’s interfering with the available horizontal space in your editor, then you’re doing something wrong. If you must use spaces, use at least three or four.

Hopefully, you code with visible white space markers. If not, then maybe that’s why you don’t see the problem with spaces. In Visual Studio, use ctrl+r ctrl+w to show white space. In Sublime Text 2, add the “draw_white_space” setting to your user preferences and set it to “all”. If you’re a serious coder, then you should have a consistent use of tabs and spaces, where tabs (usually denoted by arrows) represent the level of indentation and spaces (usually denoted by dots) represent alignment characters. Here’s an example:

--->var myObject = { color: 'red',
--->·················size: 'small',
--->·················shape: 'circle'};

This seems to confuse a lot of people in the space camp. It should be easily noticeable that the code above has one level of indentation and that spaces have been used to align the “size” and “shape” properties so they line up nicely. For some reason, the space people claim this as something that can’t be done with tabs, and then they try to demonstrate their point by incorrectly using multiple tabs to align the properties. They don’t seem to understand that tabs are only for indentation. Spaces are for alignment.

So Why are Spaces Used so Often?

With all these advantages, why are there so many advocates for spaces? Here are a few possible reasons.

1. Misunderstanding of Difference Between Indentation and Alignment

Some people have a hard time knowing when to use spaces and when to use tabs, so for them it’s easier just to use spaces all the time. This is a cop-out, and if it’s your excuse for using spaces, then you need to learn the difference.

2. Code Editors that Replace Tabs with Spaces

Many code editors, Visual Studio included, default to replacing tabs with spaces and not showing white space characters. This leads to ignorance as to what is actually happening behind the scenes, and novice coders never learn to use tabs as they’re meant to be used. It also leads to a mixture of tabs and spaces that only looks good when viewed in the original editor.

3. Copy and Paste Programmers

Many developers learned how to write code by pasting it from other sources. Unfortunately, Web browsers aren’t the best at displaying code, and Web authors weren’t sure how to insert tab characters into their tutorials. This means that a large majority of the code that is shared online uses spaces instead of tabs.

4. Sloppy, Indifferent, and Poorly Organized Coders

Many programmers don’t care about what their code looks like. “As long as it works” is their mantra. These people are usually disorganized and write code that is difficult to maintain. They are entrenched in a specific code editor and are highly resistant to change or anything that jeopardizes their current method of writing code.

I hope you don’t fall into that last group and that you care about how your code looks. Well written code should be quick to create, easy to maintain, and it should look beautiful. Maybe that last bit isn’t important to you, but maybe you’re not passionate about what you do either. Use tabs for indentation. Spread the word.