Do not work in isolation. Be as responsive as possible to your team and to the rest of KDE. If you know that you will not be reachable for a while please let others know via your team site or your team mailing list. If you do not have enough time for coordination any more please find another coordinator or a co-coordinator. Do not cling to the "title". Your work will usually only succeed as a team effort. Just as KDE as a whole.

If your team has more than one coordinator it is often a good idea to let people know who is mainly responsible for which areas (for examples: PO files, docs, web site, user feedback, bug reports) or who is generally the main contact. And please: if there are some unsolvable discussions inside your team about organizational questions, keep them internal or apply to KDE e.V. Community Working Group for the referee.

"Do not work in isolation" also means: Talk to your co-translators about what your translation should look like and what your target groups are. If your translation is for "ordinary users", including business people, it will look very different from a translation that is made for computer specialists. (Normally, KDE is not considered to be something that is "made only for geeks".) In any case: try to develop a style guide for your team.

Find standard translations for standard elements and stick to them. The archived PO translations (also known as "compendium files") at https://l10n.kde.org/team-infos.php?teamcode=$LANGUAGE will be very helpful in this respect, as will specialized translation programs like Lokalize that either allow you to search these files or provide comparable means to help you with consistency checking. Also make good use of word lists and dictionaries and mailing lists. You can also use search and compare facilities of the KDE site itself.

Develop a system of "mutual proofreading" to make sure that everybody involved sticks to the rules. This can be somewhat delicate at times (so do not be too argumentative;), but since this also provides your best means of correcting spelling mistakes and stupid errors you will have to set up such a mechanism anyway, at least in the long run. In this sense, you can find very useful the collection of scripts called Pology. Please refer to the documentation inside the scripts to learn more.

It may be a good idea to have the same person do the GUI translation and the translation of the on-line help (i.e. the documentation) of a given program. If this is not possible, the person who does the final proofreading of the documentation, the screenshots and so on should be allowed to make corrections to the PO files as well, ensuring that GUI and on-line help are "speaking the same language". It is extremely confusing to the users if the terms in the documentation are different from the terms in the actual menus of the same program.

Never commit a file to SVN without doing appropriate syntax checks as pointed out in the respective sections on GUI and doc translation. Again, the use of specialized programs (like Lokalize and Pology for POs of the GUI and Doc Translation) is highly recommended since they provide mechanisms for syntax and other checks.