Lee Crowe
Jan 4, 2011
(2 votes)

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


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.


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 Sad smile


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.


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 Winking smile



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 Smile.

Jan 04, 2011


Jan 4, 2011 12:14 PM


I've never encountered that requirement myself. Interesting. :)

I'm used to keeping the lang-files under source control though, so that when another developer downloads the project they'll get the translations for labels, buttons, etc.

An alternative could be to combine your approach with separate lang-files for webeditors.

E.g. lang_webeditors_EN.xml, lang_webeditors_ES.xml, and so forth and exclude these from source-control and keep them in a linked folder.

That way you'll hopefully avoid any discrepancies when updating translations for buttons and whatnot and trying to synch what with the webeditors have updated.

Please login to comment.
Latest blogs
Optimizely Web Experimentation Metrics

Within the domain of Optimizely Web Experimentation Metrics, the emphasis is on objective key performance indicators (KPIs) selected to assess an...

Matthew Dunn | Sep 23, 2023 | Syndicated blog

Optimizely For you Intranet

Having been at Optimizely and in the CMS industry for nearly 16 years I have seen clients’ intranet requirements go from a simple site just to hous...

Robert Folan | Sep 22, 2023

Vulnerability in EPiServer.GoogleAnalytics v3 and v4

Introduction A potential security vulnerability was detected for Optimizely Google Analytics addon (including EPiServer.GoogleAnalytics and...

Bien Nguyen | Sep 20, 2023

Overriding Optimizely’s Content Recommendations Block to Implement Custom Recommendations

Introduction The Content Recommendations add-on for Optimizely CMS dynamically recommends content from your site tailored to the interests of each...

abritt | Sep 13, 2023 | Syndicated blog