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 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.
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.
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:
resources.mail.defaultFrom.name = Support Translate5
resources.mail.defaultFrom.email = email@example.com
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:
Regarding the header in the editor
As of translate5 3.2.9 there is no header area any more when the editor is opened.
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)
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.
A own main menu can be provided by providing a own, edited layout.phtml as described above.
Or, if the layout stays the same and only some pages has to be added / disabled: use the configuration "runtimeOptions.content.mainMenu" to reconfigure the main menu and therefore the valid pages.
The structure of the JSON in runtimeOptions.content.mainMenu should be self explaining:
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).
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.
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 translate5.net 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.