Allowing web administrators to dynamically update EPiServer language files

When working with EPiServer sites, a not all that uncommon type of support case is the need to change text on a page which is not editable through the Edit mode. Quite often, this text is located in language files on the web server, and it may be rather tiresome for web editors having to send change requests to the support or development team just to change it. Perhaps, they even have to wait for the next planned release before they can get their update. I wrote a simple EPiServer Admin mode plugin which, added they get a little practice, will allow web administrators to make language file changes themselves; as well as creating new ones based on what they have already got. The source code is available at GitHub. Installation notes are included in the Readme.txt file.

This version makes use of the EPiServer Dynamic Data Store, and will only work with EPiServer CMS 6 R2.

IMPORTANT NOTE: You will want to make sure that you prevent any unauthorized access to your entire Plugins directory, or wherever you put this tool; for instance by using a location section in web.config only allowing access to WebAdmins. The way that file read and writes are currently managed in this tool makes room for quite a security issue. Read more here: Security fix for the Language File Editor tool in EPiServer CMS 6 R2

The Language File Editor

When opened, the plugin tool will display a long list of all XML files located in the EPiServer language folder. Each of these files may be edited, backed up, or removed. There is no automatic backup procedure present, so if changes are made to a file without a backup, the original information is lost.

Language File Editor 1.0 - Language file list.

If any of the language files have been backed up, an additional area will show above the file list. Here you will find a drop down list containing them all; along with a timestamp to help you find the right one. There is also a Restore button and a Delete all backups one. Restoring will, obviously, copy the backed up content into a file with the original name; creating a new one if it does no longer exist.

Language File Editor 1.0 - Backup controls.

At the top of the language file editor you will find controls for creating new language files. Here it is possible to select a pattern file which will work as a template for the new one; all the content of this file is contained in the editor’s text boxes as an aid for the person translating. The drop down list holding the patterns is populated using the XML files in the language folder.

Language File Editor 1.0 - Create new controls.

When creating a new file, or editing an old one, the web administrator will find themselves in a collapsable/expandable XML tree mirroring the content of the language file in question. If they are creating a new file they will be given the opportunity to give it a name in the top control box; this will be disabled when editing existing files.

Language File Editor 1.0 - Language file edit view.

As you can see the XML declaration is not editable. This is done by choise because it is highly unlikey that web administrators will ever need to change it. When altering attributes or content in the tree structure, the change is stored using JavaScript based functionality. Since it is not necessary to send information that has not been edited, this array is the only content that is sent back to the server on save; using JQuery AJAX and JSON. As a visual support for the translator, the text boxes will change color when they are updated.

Not losing changes on new release

So. Great. But what about deployment procedure? Will the changes made by web administrators be lost when there is a new release of the site? The short anwer is no. It won’t be. And it is not necessary to synchronize the files manually either. As soon as the web administrator hits the Save button on the editor page, all of the updated (and previously updated) fields are stored on the server, allowing the developers to reapply the changes by the click of a button. However, only the latest change made to a field is kept, so there is no history tracking involved.

Language File Editor 1.0 - Reapply language file changes controls.

Both the change tracking and the language file backups are stored in the EPiServer Dynamic Data Store, meaning that you will need to make changes if you are to run this in earlier versions than EPiServer CMS 6 R2. There is also a bit of audit logging going on, so if you use log4net you will see who is changing what and when.

I will be happy to accept bug reports, or feedback on this; so don’t be shy. And remember to always make backups as you are not blaming me if anything goes south; using this is all on you.

15 Comments

  1. Andreas September 5, 2011
    • mathias September 5, 2011
  2. Johan Book December 2, 2011
    • Mathias Kunto December 7, 2011
  3. Øyvind Hognestad January 24, 2012
    • Mathias Kunto January 28, 2012
  4. Adam Jenkin May 3, 2012
    • Mathias Kunto May 4, 2012
  5. Sachin July 8, 2012
    • Mathias Kunto July 8, 2012
  6. Hannu Hartikainen January 31, 2014
    • Mathias Kunto January 31, 2014
  7. Hannu Hartikainen March 25, 2014
    • Mathias Kunto March 30, 2014
    • Mathias Kunto April 12, 2014

Leave a Reply