Last updated February 16, 2012.
This page is aimed at administrators of the localize.drupal.org site itself. It might help understand processes used by site admins for others as well.
Before adding new translation teams
The existing translation teams are all listed at http://localize.drupal.org/. All languages correspond to a language set up with the built-in locale UI and an organic group set up with l10n_groups (from the l10n_server module suite). A block titled "Set up your group here!" explains the start of the process for people proposing new languages. The waiting queue for languages to be added can be found at http://drupal.org/project/issues/localizedrupalorg?text=&status=Open&pri...
If the language already exists
If the language already exists, just point out that the submitter can/should join the existing translation team. Most teams are open to join (depends on OG settings). If there is a dispute in the team, solving that by opening yet another variant would not work, it is eventually bad for the user.
If the language is a variant of an existing one
If the new language is a variant of an existing one, point out that localize.drupal.org does not support inheriting translations from an existing language. People can manually import the "parent" language translations from time to time but that would overwrite customized translations or serve as a huge set of suggestions that is tedious to merge in on the UI. All-in-all it makes for lots of manual work and people might not want to do that. Localize.drupal.org might support basing translations on foreign languages in the future if someone works out a solution. See http://drupal.org/node/608488
If the language already has a translation server or a d.o (old CVS based) translation repository
Make sure to check if there is existing work done on the translation. Some people were understandably not patient waiting for drupal.org to have a translation server and started to run their own. If there is existing work, it is best to make sure they are not duplicating it again and respect the existing work done. Always ask if they know of existing work in this language if unsure. Google for the language name and Drupal and see if you have any suspicious results.
If you determined the new translation team should be added
Make sure to ask the following questions:
- Is there any existing work that they know of? (See also above)
- Do they have more people to work on the team? Translating Drupal is tedious.
- What is the W3C Language Tag codified language code for their language. It is very important we use a standard language code so Drupal is interoperable on the web. See http://www.w3.org/International/articles/language-tags/ for more info, http://rishida.net/utils/subtags/ to verify if the language code is known to W3C and is correct. Country codes as language codes will not do it.
- What is the plural formula for their language (see later why we need this). http://translate.sourceforge.net/wiki/l10n/pluralforms has plural formulas for many languages but it is not 100% accurate, so double check with he person proposing the team.
Once you get all the info, actually add the language
- Add the language on http://localize.drupal.org/admin/settings/language/add. You'll need the plural formula right there if its a "custom language" (not in the predefined list). If you add the language from the predefined list, go back to edit the language and specify the plural formula there. The number of plurals drives the input fields for translations so it is very important to get this right out of the gate. Localize.drupal.org runs http://drupal.org/project/l10n_pconfig to edit the plural forms on the admin interface.
- Add the language group on http://localize.drupal.org/node/add/l10n-group.
- The group name and description should be standard text like "Greek team" (if adding Greek).
- Select the right language in the language dropdown but *do leave* group language (radio button group) as neutral. Spotty random UI translations in the given language would not be good. People requested to make the l.d.o UI available in their language (http://drupal.org/node/604052) but it would need a lot more work to do.
- Leave everything else as default, until you reach URL alias at close to the bottom.
- Set the URL alias to "languages/el" (where 'el' is the language code).
- Set the Group manager (in authoring information) to the group lead who applied to start out the team.
- Once you submit the above node creation form, you should land on the group node page. Here you'll need to set up group member permissions to finish creating the group. In the sidebar, you'll see a "Greek team" block (if the language is Greek), which has a "1 member" item that is a link. You'll find a "Configure roles" tab on that page, which lets you assign roles inside the group to members. For the admin to be able to further distribute power in the group, you need to grant "translation community manager" to the single member (the admin). It is also practical to grant both moderation permissions (self-moderator and community moderator) just to speed up the work for the new team maintainer.
- Now with the team created, post a positive message on the issue and close it off as fixed. Replace "languages/el", and @username as appropriate in this text:
I've created the team at http://localize.drupal.org/languages/el and made @username the initial owner / admin. You can add any number of other admins and manage group level permissions of people.
Please report issues as you find them! Your team members can now join and help import existing translations and work on more translations. Anybody can sign up for being a member of the team and they will be able to submit suggestions right away. The initial admin can change permissions of people signing up, widening their capabilities. See http://localize.drupal.org/node/616 for explanation on how. It is highly suggested to grant both moderation permissions to those who you also designate admins.
Welcome on board!
Handling leadership disputes
Unfortunately languages don't really have a way to fork translations unlike modules. If someone is not happy with a module, they can go off and create their sandbox or their "better X" module, but it is not so with translations. There is no option to have "Better Greek" or "Improved Russian" in the translations. So people need to get to the same page. Sometimes this leads to power struggles and disputes among translation team leads and team lead aspirers.
Handling these cases is best by asking all interested parties to open a drupal.org webmasters issue (which is the queue for localize.drupal.org team questions) and state all sides of the story there. Then try to do your best to help avoid it going worse and try and find a good way to settle the issue. Forcing people out of their seat as team maintainers or forcibly adding people complaining as co-maintainers without further discussion might not end up well, so better discuss first and see how best to proceed. Ideally the discussion itself will help resolve the issue and you'll not need to intervene.