Page tree
Skip to end of metadata
Go to start of metadata

Currently there are multiple possibilities to do a skinning of translate5:


In order that the public files can be accessed, the directory APPLICATION_ROOT/client-specific/public must be symlinked to APPLICATION_ROOT/public/client-specific

In other words: "APPLICATION_ROOT/public/client-specific" is the public available directory to serve the data via the webserver, and must point to APPLICATION_ROOT/client-specific/public which contains the the public data, all located at the central directory "client-specific".


In the configurations-table Zf_configuration modify the following config:

runtimeOptions.publicAdditions.css = ['css/editorAdditions.css']

runtimeOptions.publicAdditions.css is a array, so you can add one or multiple css files.

Hint for own skinning

The editorAdditions.css file provided by translate5 contains the default translate5 logo and must therefore removed or overwritten by own css.

The CSS files of an own skin has to be placed in


This results in the following Zf_configuration setting:

runtimeOptions.publicAdditions.css = ['client-specific/editorAdditions.css']

The public directory above is already linked to the WEBROOT/client-specific/public directory. From there all custom styles and images can be accessed.

If MittagQI is maintaining the client-specific skin, the content of client-specific is provided by the build script and the deployment process is responsible to put the files in the desired place. For the unified skinning mechanism described below this must be changed, and the path to the CSS file(s) would then be:

Logo and other image files

As specified above the default logo is defined by the default delivered translate5 css.

All other files needed by the skin should be delivered in the client-specific/public directory, so it is possible to do any customizing possible with images and css, also the background of the header.

Custom translations

In addition to adopting the layout, also the application texts can be customized. Therefore the internal used translation mechanism of translate5 can be used.

Create a folder "client-specific/locales" and create there XLIFF files. The filename for german text overrides is for example: "de.xliff". This file must contain a valid xliff and file body structure and one trans-unit for each text you want to override (trans-units you do not want to change should not be part of your xliff).

The id of the transunit tag must contain the base64-encoded string, that is translated. This is important, since it is used for matching.  

<?xml version="1.0"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <!-- the transunit-ID should contain the base64-encoded source-string als used in the php source-code. This ID is used for matching. -->
 <file original="php-sourcecode" source-language="ha" target-language="en" datatype="php">
    			<trans-unit id='QXV0b3I='>

Customize E-Mail sender

To customize the E-Mail address which is used as default mail sender just set the following configs in the application/config/installation.ini: = Support Translate5 =

Favicon file (small logo in the browser tab)

A customized favicon is also supported by translate5. Place your favicon file also in the client-specific/public directory. The name must be favicon.ico and it must be a valid ico file.

The path to your favicon.ico file can be configured with the configuration parameter

runtimeOptions.server.pathToIMAGES = '/client-specific/'

So this would be the correct configuration if you have placed your favicon.ico in "client-specific/public". Yes this is correct, since the path "client-specific/public" in the root folder is mapped to the webroot folder public/client-specific.

Additional HTML structure in the translate5 Header (branding)

Regarding the header in all places inside the login except the editor

In addition to CSS and images above, own HTML structure can be added to the translate5 header. Therefore the header provides an container where HTML can be added  by the following config in the DB, category layout:

runtimeOptions.editor.branding = 'OWN HTML'

The container containing the above HTML is addressable by the following CSS:

#head-panel .head-panel-brand
Code/Text in runtimeOptions.editor.branding and runtimeOptions.editor.customHtmlContaine will be send through the translate5 translation mechanism. So if you have defined a corresponding translation, the content will be translated into the current language.

Regarding the header  in the editor

As of translate5 3.2.9 there is no header area any more when the editor is opened.

However there is an optional (normally invisible) area that can be used to define custom HTML  in the right column of the translate5 editor. For defining javascript logic or loading an external html content an iframe should be used.

  • To only display simple html content and text use the runtimeOptions.editor.customHtmlContainer configuration property. The content of this property will be send through the translate5 translation mechanism.
  • To display more complex html/javascript content, use the runtimeOptions.editor.editorBrandingSource property. Define the page url from where the content will be loaded.
    • ex: with /client-specific/branding.phtml as value for runtimeOptions.editor.editorBrandingSource property, the content from branding.phtml file located in "translate5root"/client-specific/public/ will be loaded.
branding.phtml example content
//here you can define your custom php code

echo 'Hello World. <br/>';

<!-- define your html here  -->
<a href="" target="_blank">Link to</a>

<script type="text/javascript">
//The task object is located in the parent iframe!.
//Task data object example:

alert('The task name is :'+task.get('taskName'));

The content from the Zf_configuration variable runtimeOptions.editor.customHtmlContainer config will be shown in the branding area(the area above the editor action buttons) in the translate5 editor.

Editor only Mode

In "editor only mode" the following two configuration values are used:

runtimeOptions.headerOptions.height → height in pixel of the header (deprecated: From translate5-3.2.9 and in the future, the translate5 editor is without the standard header)

runtimeOptions.headerOptions.pathToHeaderFile → path to a HTML file which is loaded as iframe into the header (deprecated: From translate5-3.2.9 and in the future, the translate5 editor is without the standard header)

runtimeOptions.editor.toolbar.hideLogoutButton → hide the logout button in the segments editor header (set the value to 1 and the button will be hidden)

runtimeOptions.editor.toolbar.hideLeaveTaskButton → hide the leave task button in the segments editor header (set the value to 1 and the button will be hidden)

Tag Images

Segment Tags are rendered in Translate5 as HTML or as images in edited segments. The HTML ones can be styled by using CSS, see above. For the images there are several configuration parameters.
See therefore the DB config category imagetag. This category contains all necessary configurations.

MQM Image Tags

For MQM tagging also image tags are used. This images can also be configured like the above Image Tags. All the values existing for imageTags can also be changed for MQM Tags. The Image Tag settings are the default values for MQM Tags!

Per default some colors are different for MQM Tags, so the are listed in the DB Config category qmimagetag. The namespace for the mqm tag settings starts with: runtimeOptions.imageTags.qmSubSegment.


CSS, image and other public files

The used CSS file by the default layout is defined in the following DB config (category layout):

runtimeOptions.server.pathToCSS = '/css/translate5.css?v=2'

The first config “pathToCSS” defines the CSS file included by the default layout, and can therefore be customized. Another way to add more or customize the included CSS files is to provide a customized layout.

All public files like images and so on, must be placed in client-specific/public either managed manually by the client, or by MittagQI by the build and deploy process:



The place of the layout file is defined in the application.ini and can can overwritten by adding the following setting in the installation.ini:

resources.layout.layoutPath = APPLICATION_PATH "/client-specific/layouts/"

For customizing a own layout.phtml has to been provided on the above location.

By customizing the layout, own CSS can be supplied. For using the default layout see the above section about CSS and other public files.

Important: when defining custom layout.phtml, inside the head html tag, "<?=$this->headScript()?>" call is required (see example below). This will render the required javascript scripts used for the translate5 authentication.

Layout.phtml head tag example
	<!-- Insert the required javascript code -->
<body> ...

Own Menu

A own main menu can be provided by providing a own, edited layout.phtml as described above.

View Scripts

Own View Scripts can be provided in


You can either overwrite existing view files, by placing identically named files in the above defined directory, or you can add completly new view scripts which is described later.
<modul> in the above path ist the name of the actual-used modul. Normaly this should be "default" for ordinary frame-pages.

Own Pages / Own Viewscripts / Disable default Viewscripts

If you want to provide your own pages in your skin, this is also possible in a simple manner. Each page is provided by one view script. So you can simply add own view scripts. They are callable as all other view scripts:


For security reasons and to provide the posibility to deactivate default views, all valid views has to be listed in the following menu DB config, see above.

Overwrite default mail templates

Mail templates are simply view scripts. So please see above on how to overwrite view scripts, if you want your completely own mails. If you only need to change some texts we recommend to overwrite the translations of certain parts of the mails (see below).

Termportal & InstantTranslate

To customize the termportal for all view phtml files the same mechanisms can be used as mentioned above.

The main difference is the handling of custom CSS, and customized stuff like an own HTML title.

To prevent overwriting the whole termportal layout, this essential parts are configured in the layoutConfig.php which can be overwritten in client-specific to reconfigure just that parts.

Example in setting a custom logo in instanttranslate.

For termportal just change the file paths accordingly.

//Example for InstantTranslate - for TermPortal save the file as "client-specific/views/editor/scripts/termportal/layoutConfig.php"
// set the default title again
$this->layout()->title = $this->headTitle();
// append a new stylesheet containing the logo overwrite

  This is the CSS file referenced above in layoutConfig
  The below references image must be saved in "client-specific/public/images/yourLogo.png"
#logo {
    background: url(images/yourLogo.png) no-repeat left top;
    flex: 0 0 300px;


You can make client-specific translations. Therefor you should place your translation-xliff-files into


Client-specific translation-files are loaded automatic after all other translation-files. So you can overwrite existing translations. Also you can define new translations which you use in your special views or layouts or even in your editor-branding as mentioned above.

Other currently used client specific files


For license reasons arial.ttf cant be included in the public translate5 repository, so we deliver it per client / installation. For the install-and-update-kit, this file should be fetched like an external dependency. This approach should also ensure that the file wont be deleted accidentally on further updates.

With the unified skinning mechanism this files has to kept and copied by the specific deploy scripts until the final release of the install-and-update-kit.


This file is currently provided as some kind of a global specific file in:


Its needed only by our instances. In general this can be used then as specific/clientX/index_prerun.php.
With the unified skinning mechanism this file is included automatically if it exists.

.htaccess and .htpasswd

If above apache config files are needed, this is not in the responsibility of  the install-and-update-kit, so they should be therefore completely ignored.

  • No labels

1 Comment

  1. Copied from file "skinning", contains typos and non understandable content, must be reworked.