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
Plug-in manager is back in CMS 12

Plug-in manager is back in the UI, what is it and how can i use it?

Luc Gosso (MVP) | Oct 6, 2022 | Syndicated blog

Display Child Pages in Content Delivery API Response

The below example will implement an instance of IContentConverterProvider to customise the serialisation of PageData and output child pages in the...

Minesh Shah (Netcel) | Oct 4, 2022

Bring the Report Center back in Optimizely CMS 12

The Report Center has been a part of Optimizely CMS since its first debut in version 5R2 in 2008, but in CMS 12, it's removed! Don't despair! Make...

Tomas Hensrud Gulla | Oct 4, 2022 | Syndicated blog

Customizing Property Lists in Optimizely CMS

Generic property lists is a cool editorial feature that has gained a lot of popularity - in spite of still being unsupported (officially). But if y...

Allan Thraen | Oct 2, 2022 | Syndicated blog