Until recently, website localization was primarily approached in three ways.
- In the traditional file-based approach, project managers would take their loose collection of files (e.g., HTML, PHP, XML, etc.) and simply hand the content off to translation. Those translated files, once returned, would be passed on to the web developers to build the target-language versions of the site.
- Then there was the API “connectors” approach to website localization. Using this method, your web content management system (WCMS) (e.g., Drupal, WordPress, Joomla, etc.) could be connected to a translation management system (TMS) via an application programming interface (API). Source content would be pushed to the TMS through the connector to the translation vendor and routed back to the WCMS through the API.
- From about 2010 onward, we saw the rise of DNS proxy or “mirror-based” approaches to localization. No fussing around with APIs—you would get a web mirror where your localized website is stored and managed by a third-party server with a built-in TMS.
Each of these legacy methods have their associated risks and opportunities as well as varying levels of localized content management involvement.
These third-party web localization services have a number of features in common:
- Online editor for translation
- Option for in-context editing of translated content
- Option to add machine- or human-translated content