View source for Translate Open-Xchange to supported language

= Documents to be translated =

==User guide==

The user guide currently has 64011 words (based on 6.20)

==What's New Guide==

The What's New Guide currently has 1327 words (based on 6.20)

==OXtender for Business Mobility Guide==

The OXtender for Business Mobility Guide currently has 5716 words (based on 6.20)

==OXtender for Syncml Guide==

The OXtender for Syncml Guide currently has 860 words (based on 6.20)

==Mobile App Guide==

The Mobile App Guide currently has 1016 words (based on 6.20)

==Voip Guide==

The Voip Guide currently has 1523 words (based on 6.20)

==OXtender 1/2 user guide==

The OXtender 2 for MS Outlook Guide currently has 10244 words (based on 6.20)

= User interfaces to be translated =

==OX6 GUI==

The OX6 user interface currently has the following word count (based on 6.20):
5265	ox.po
2531	server.po
8923	errors.po

==Plug-ins==

==OXtender1/2 UI==

= Requirements =

== 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:

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

===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. &amp; 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:

<pre>
#. 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"
</pre>

===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:

<pre>
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"
</pre>

===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:

<pre>
Plural-Forms: nplurals=2; plural=n == 1 ? 0 : 1;
</pre>

A list of plural entries for the single languages can be found here:<br>
http://translate.sourceforge.net/wiki/l10n/pluralforms

==xml files==

===Tools===

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

==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====

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.