Documents to be translated

Please note: Not all documents necessarily need to be translated. It depends on the requirements.

User guide

The User Guide explains the user interface to the end user. The online help that is visible in the user interface has the same content and is built from the same source as the user guide.

BriefGuide OX6User

The BriefGuide OX6User gives an overview of the differences between OX and OXAppsuite

OXtender for Business Mobility Guide

The OXtender for Business Mobility Guide explains how to synchronize E-Mails and PIM data between the groupware server and your mobile phone and lists all supported devices.

Mobile Web Interface Guide

The Mobile Web Interface Guide explains how to access data on the Open-Xchange Server with your Smartphone

Connector for MS Outlook Guide

The Connector for MS Outlook Guide explains the synchronization between the Open-Xchange Server data and the Outlook client to the end user

User interfaces to be translated

Please note: Not all ui files necessarily need to be translated. It depends on the requirements.

OXAppsuite GUI

Consists of several .po files and includes also the guided tours

Connector for MS Outlook UI

The Connector for MS Outlook user interface consists of 'faked' .po files i.e. the files are not generated with gettext, but basically they work in the same way as any other .po file. If a .po file editor displays an error though it might be due to this fact.

Screen shots to be localized

The screen shots for MS Outlook Guide need to be localized. This is mostly done by us and requires 1-2 days of work.

Quality checks

For quality checks there's a prototype where the newest translations are visible in certain intervals. This prototype has to be checked for:

  • the string length - some languages are more verbose than others
  • the context - sometimes there are several words in one language whereas there might be only one in English i.e., the translation in a specific context might be wrong
  • in some languages the address formats, date formats or the sorting is different. This has to be checked and any behavior that is not already covered by the .po files entries should be communicated

Please ask for the account data if you need to access the prototype in order to check your translations


Tools for translating the UI

For the UI translation a tool like KBabel, Lokalize or poEdit is required. It's also possible to translate the files in a text editor, but it's error-prone.

Tools for translating the manuals

For the translation of the manuals a TM tool is strongly recommended. You can also convert your files to .po. But that has to be done from the beginning. Once, the initial translation is done and no TM tool has been used, there's no alignment. This can be done later though with an alignment tool, but it's essential to use a tool from the beginning. As we have many updates in the single files, also many last minute updates, a translation tool is a must have. It's also possible to use a diff tool, but that way you cannot make use of similar translations or build up a terminology data base with direct access while translating.

File formats

.po files

The letters PO in .po files means Portable Object, to distinguish it from .mo files, where MO stands for Machine Object.

A .po file is made up of many entries, each entry holding the relation between an original untranslated string and its corresponding translation. An entry can look like this:

#: acceptdeny.xml:27 <br>
msgid "You have unconfirmed appointments" 
msgstr "U hebt onbevestigde afspraken"

fuzzy entries

This flag can be generated by the msgmerge program or it can be inserted by the translator. It shows that the msgstr string might no longer be correct. The translator has to check whether the translation requires further modification. Once satisfied with the translation, the fuzzy attribute has to be removed.

Placeholders and shortcuts

Placeholders like %2$s need to stay as they read in other information. & indicates a shortcut and also needs to stay. They must not be modified in any way (e.g., no spaces between the placeholder elements). Please always read the comments in the files.

Address formats

Please always take a look at the comments filed in the .po files. There are some strings that must not be translated, but only adjusted to your language i.e. re-ordered or changed punctuation-wise. Please have a look at the following examples:

#. Address format for 2 line display (card view).
#. Only change the order and punctuation.
#. \n separates multiple lines. Other punctuation appears as-is.
#. Available fields are: street, postal_code, city, state, country
msgid ""
"postal_code city"
msgstr ""
"postal_code city"

#. Address format for 4 line display.
#. Only change the order and punctuation.
#. \n separates multiple lines. Other punctuation appears as-is.
#. Available fields are: street, postal_code, city, state, country
msgid ""
"postal_code city\n"
msgstr ""
"postal_code city\n"

#. The address format for input fields.
#. Only change the order.
#. Comma (,) separates lines, slash (/) separates fields in a line.
msgid "street,postal_code/city,country,state"
msgstr "street,postal_code/city,country,state"

Date formats

Please always have a look at the comments field in the .po file. If there's none, stick to your language rules. Here are some date format examples for French:

msgid "d.M.yy"
msgstr "j.M.aa"

msgid "d.M.yyyy"
msgstr "j.M.aaaa"

msgid "d.MM.yy"
msgstr "j.MM.aa"

msgid "dd-MMM-yy"
msgstr "jj-MMM-aa"

msgid "dd.MM.yy"
msgstr "jj.MM.aa"

msgid "dd.MM.yyyy"
msgstr "jj.MM.aaaa"

msgid "dd/MM/yy"
msgstr "jj/MM/aa"

msgid "dd/MM/yyyy"
msgstr "jj/MM/aaaa"

Plural entries

Different language families have different number of plural forms. To solve this issue, there is a plural entry in the header of a .po file. The plural form information can look like this:

Plural-Forms: nplurals=2; plural=n == 1 ? 0 : 1;

A list of plural entries for the single languages can be found here:

xml files


For updates best use a TM system.
For just editing a xml file, OXygen from renderx is a good choice.

xml syntax

Hierarchical elements

The hierarchical elements roughly structure a document. They include typical root elements like book and article. preface, chapter, appendix, bibliography, glossary, index which structure a document in single parts. To get a finer hierarchical structure there are the elements sect1 to sect5.

Info elements

Of course there are to be elements that contain the actual content of the document: paragraphs, lists, tables, images. The most important element is para. It contains a paragraph.

Markup elements

As DocBook was developed for technical documentation there is a great number of elements for marking up technical areas. Some areas covered are e.g. user interfaces (keycombo, mousebutton, menuchoice, guiicon), operating systems (prompt, command, errorcode, filename) and others.

role elements

It exists for any element and there are no given values. That way it is possible to generate subclasses of all elements. Processing tools can then treat the element differently for each subclass.


Translate all text within an opening and ending tag e.g.: <para>Do translate </para> Also take care of any changed role elements, vendor attributes or figure names.

Do not translate

Do not translate any words within tags: <do not translate> Just adapt any possibly changed tag attributes so that they match the English template.