Using Symbolic links for EPiServer lang folders to prevent unintentional file modifications

Introduction

Over time I have worked on a few multi lingual sites that have had requirements to allow label text throughout the site to be translatable.  This would usually be done by adding text to the relevant language files within the “lang” folder.

Some projects however have had the requirement to allow the editors to update the relevant nodes within the relevant language xml files.  This functionality has been provided by utilising the “ManageLanguages” EPiCode plugin.

Danger!!!

Managing language text is pretty straight forward but there are risks involved.  Issues can crop up when new nodes need to be added or updated.  This usually involves pulling down the live language files and issuing a temporary content freeze (on the language files) and then making the necessary amends and updating the live files.

Again, this is straight forward but additional risks can be introduced when multiple developers are working on a project at different times and deploying with a limited understanding of the full working of the web application.  Ideally, a technical lead or a developer with a solid understanding of an application should be performing a deployment but this is not always possible.

Now I will get to the point.  The issue that has cropped up on a number of occasions is the fact that the “lang” folder is usually under source control and has sometimes been deployed to the live environments.  The files in the “lang” folder are usually out of date so when the “lang” folder is deployed various translations are lost from the site

Solution

There are solutions to this problem, but in my opinion the safest solution of the solutions below is Solution 2.

Solution 1

Do not include the “lang” folder as part of your web application and enforce a rule to make sure that the “lang” folder never gets deployed.

Risk: Somebody will forget and deploy it anyway.

Solution 2

Create a symbolic for the “lang” folder on the relevant environments.

How?

A language folder would need to be created which lives outside of the web application root but contains all of the relevant language xml files.

A symbolic link could then be created via the command line to create a linked “lang” folder within the web application root (The “lang” folder should not exist within the web application root before running this tool).

Example below:

mklink /d “c:\EPiServer\Sites\EPi6Demo\lang” “c:\EPiServer\Sites\EPi6DemoLanguageFiles\”

As the language files will now exist outside of the application root there will be no risk of accidentally overwriting the language files when deploying.  Any updates to these files should be intentional

Conclusion

I may be one of a few people who have experienced this problem, but if there are other people out there that have suffered this I hope that the use of symbolic links may prove useful in the future to prevent language files from being accidentally overwrote .