AppSuite:Translate Open-Xchange to supported language
- 1 Documents to be translated
- 2 User interfaces to be translated
- 3 Screen shots to be localized
- 4 Quality checks
- 5 Requirements
- 6 File formats
Documents to be translated
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.
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
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.
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.
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"
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.
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). #. #. DO NOT TRANSLATE THE FIELD NAMES! #. #. 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 "" "street\n" "postal_code city" msgstr "" "street\n" "postal_code city" #. Address format for 4 line display. #. #. DO NOT TRANSLATE THE FIELD NAMES! #. #. 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 "" "street\n" "postal_code city\n" "state\n" "country" msgstr "" "street\n" "postal_code city\n" "state\n" "country" #. The address format for input fields. #. #. DO NOT TRANSLATE THE FIELD NAMES! #. #. 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"
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"
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:
For updates best use a TM system.
For just editing a xml file, OXygen from renderx is a good choice.
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.
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.
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.
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.