An Analog CMS. Photo Credit: mikecogh via Compfight cc

An Analog CMS. Photo Credit: mikecogh via Compfight cc

If you are translating your digital assets, your language service partner will ask about your Content Management System.  Your CMS is the software system used for creating and maintaining your website (and other digital content). A Fortune 500 company will generally use ECMs or Enterprise Content Management Systems, while a smaller business might use a popular CMS (WordPress, Drupal, Joomla) or a web-site builder (WIX, Weebly). Organizations with in-house technical talent may build their own CMS.  Not every CMS is set up for an efficient translation workflow, but there is always a path. Some will require more time and expense than others. When assessing the translation-readiness of a CMS we consider two core functions: language encoding and content export.

Language Encoding: UTF-8

The most important question is whether your CMS publishes your web pages using UTF-8 language encoding.  UTF-8 provides the widest support for languages while minimizing file size.  Other encoding declarations (like ISO-8859-1) may look good in English, but they do not support many international characters. If your non-UTF-8 pages are translated and then uploaded without conversion, the content will be garbled. A Spanish language page will appear buggy and show strange characters whenever an accent or tilde mark appears, and a Chinese or Arabic web page would appear as complete gibberish.

Most commercial CMS systems will store and publish web pages in UTF-8 by default. If you are using content management that was built in-house, you should confirm your pages are correctly encoded.  View the source code and look for “charset=” somewhere in the document’s meta-data, or simply use this handy web-based tool. You’ll also want to confirm that the backend database that stores your content is Unicode compliant.  If something other than UTF-8 was used, you will likely need to change your encoding before launching the localization process.  A good starting point for more information on encoding is available at Sitepoint, the web developer resource.  Or ask us. We are happy to help.

Do you need help translating your content?
Contact us.

 

Exporting Your Content

It is usually much better practice to send an export of your website to the localization team than to have them log directly into your CMS. Not only does this prevent potential security issues, it allows the team to take advantage of their own translation technology, including Computer Aided Translation (CAT) tools and translation memories to ensure consistency. If you’re using a website builder like WIX, content export may not be a simple option. In those cases, you will need to decide whether you want the translator to log into your system directly, or cut and paste the content into a new document. It is generally advisable to avoid cutting and pasting.

The easiest format for translation teams to work with is called XLIFF (XML Localization Interchange File Format). This is a particular type of XML file used widely in the translation industry. This can be opened by most CAT tools and presents only those elements of the site that need translation. Most CMSs in use today, however, cannot export XLIFFs automatically, but should be able to export another form of XML file. Technology-savvy language service partners can usually work with these files, but will need to consult with you to confirm translatable and not-translatable segments.

Example of customer XML file, highlighted for translatable (green) and not translatable (red) fields.

Example of customer XML file, highlighted for translatable (green) and not translatable (red) fields.

You will also want to confirm that you are exporting not only your site content, but also your navigation menus and headers and footers. WordPress users will find that their menus can be exported as files with the “.PO“ extension, while more robust CMS systems typically include everything in a single XML export. A great way to confirm you are getting everything in the export is to have your language partner do a “pseudo-translation.” They can take your exported files, run a quick fake translation on them and then send them back for you to import and make sure you aren’t missing chunks of content.

Frequent Updates?

How often do you update your site and how many of those updates do you want to see in your translated versions? If a lot of updates are happening on a weekly basis, you might want to consider more direct, dynamic connections to your CMS, such as those provided by proxy services, like Smartling or Easyling. Ask your language service partner if they work with these providers and how they can help you make a plan for translation on an ongoing basis.

Conclusion

Localization of your website can carry many benefits. Your language service partner can evaluate your current CMS and get you on the right path. If you are considering making your website mobile-friendly, it may be a good time to evaluate and possibly convert your CMS as well. If your CMS does not separate content from its display, for example, any type of localization or customization will be difficult. Your language service partner can guide you through the process and make sure you are well-positioned for localization now and into the future.