Translator registration is a feature that needs to be developped on multilingual cms, and cannot be considered as a simple monolingual user registration.
Translator registration can be managed by the translator him/herself, or by the translation manager. Of course translator, translation manager and proofreader too, should belong to automatically created groups.
First, people who wish to register as translators should obviously be presented with a nice clear visual interface for that purpose when registering. Many sites will want to have as many translators as possible, and in that case enticements to become a translator should be available in as many places as possible on the site, on the pages to be translated of course, but also for instance in the My Tiki interface.
On the other hand, some sites with very organized professional translation activities will prefer to have translators registered, managed and authorized by the translation manager only, with average users only presented with the option of reading translated pages. In such cases enticements can disappear, and settings can even disappear from the translator's user interface.
The basic translator identification feature should obviously be the possibility to specify the languages that the translator can manage: source language(s) and target language(s). Thereafter the translator should see the Translate button only for source languages for which s/he has subscribed, and when deciding to translate a text should be proposed a scrolling list with only the the languages to which s/he has subscribed. This is an application to the translator's work interface of the Language exclusion concept.
In practice it is most often strongly advisable to restrict the number of target languages to which a translator can subscribe, and therefore Admin should be able to specify the number of available choices. In some cases the translation manager should be able to remove or add one language for a specific person.
A second obvious feature is the capacity to warn the translator that translations are requested for the subscribed pairs of languages (source language -> target language). This could be available by web interface, and in many cases by mail, if you employ translators that are not volunteers and take no interest in your site except as a job.
It should be assumed as a rule that the translator will have no ability as a webmaster. Better to start this way, and add permissions to individuals if needed. In particular, the conceptors of a multilingual cms should not believe that the future translators will understand anything in the programming of that multilingual cms. Therefore the distinction between Container multilingual and Content multilingual roles should be methodically observed.