Custom Translation Admin UI


The current translation workflow in the admin does not work well for large multilingual sites. Especially if different people (e.g. dedicated translators) maintain the website content.

It would be good to have a dedicated view for that.


  • Custom “Content translations” sidebar item
  • grid with object type, object label, language, status, editor, etc.
  • filter possibilities for object types, languages, translation status, etc.

It should be possible to quickly identify all missing or incomplete translations

export and import possibilities to allow offline/external translations

Any thoughts or other ideas on this one?

PS: FIRST! :slight_smile:


Especially +1 for import and export - I think these are most important for working with translation agencies that will use their own tools (to avoid retraining, etc.).

In addition to the dedicated UI, we should have easy navigation into the UI when viewing records that have/need translation throughout the admin UI (site tree pages, data manager objects, assets, etc.).

Next step to make this happen I think: some wireframe/screenshot of how this might look and work. It’s not on our immediate roadmap, but the admin UI could be sufficiently standalone to make this a good project for anyone willing to get involved.


Quick online research:
We could use the format XLIFF for import and export. It seems to be supported by various tools and services.

I guess using properties-files like we do for the admin UI i18n files makes less sense as the translation content could get more complex.


what about having an UI where you can see two languages next to each other? I’ve seen this in other CMS, where you have two frames containing two languages, where you are able to choose the language in each frame. It’s like in Zanata.


I would second Dom’s suggestion to focus on import/export first. I mean professional translators use offline and online tools that are far better than anything we could implement within the admin, e.g. those systems have translation memories and do suggestions based on similar translated content.
I don’t say that we don’t need it. It would be good to have what you mentioned. Left text always readonly the original content, right text area the translated content - language selectable via dropdown. Or do you mean the frontend UI?

For the export I have the following in mind:

  • select object types to export (select/deselect all option would be good)
  • select languages to export
  • produces XLIFF file format
  • it would be cool to have granular permissions, also on content, e.g. export of only a specific language or object type allowed

Import gets more tricky. We would need to have some kind of preview and approval workflow. Maybe the draft status can be used for this one. But there are nasty exceptions, e.g. while importing there is already a draft version on a specific translation object.

Oh… and if we are talking about drafts - even though this is a different topic - but it kind of would belong to this workflow as well.
We would need a single UI to bulk preview/publish drafts (from different object types and all at once).
Think of a grid that you can filter for all objects that have draft changes, quickly examine all those drafts and then publish all at once.


No, not in the frontend. I think this should only be available in the admin interface.


I was just wondering what you mean with “frame”. I thought you mean the frontend quick edit possibility - and that having side-by-side.


I was thinking of a side-by-side in the admin. Like here:
In the frontend I wouldn’t do any multilanguage stuff. You’re working on a specific page in a specific language. Offering multilanguage stuff here is too complicated for Devs and especially for the enduser.


I think the same. Doing language by language should be ok and done in the backend.
The screen you linked is very similar to our synch screens we have in the old system, works great for endusers without bigger issues.
We implemented a complete workflow in the current platform that allows users with permission to order translations to select Users that have the Role Translator. The translators are notified by email and see the orders on the start screen of the backend. When they finish a translation of an object the User who ordered the translation is notified, checks the translation and gives approval if ok.

For bigger clients it is ok to work with import/export but by experience it is to expensive for single Hotels to work with external. And in addition it was always difficult with an external translator because of missing context and formattings done in the CK-Editor. So we had a webservice with external agencies (onlinetranslate24) but it wasn`t used by our hotels. In fact they always find somebody they know who is able to do a translation. No comment about quality of the results.

So from my point of view a translation workflow should support both options.