Localize.drupal.org 本地化群组管理员指南

英文原文：Localize.drupal.org administrator guide
更新于2012年2月16日

此文的对象是 localize.drupal.org 网站自身的管理员。也可以帮助其他站点的管理员理解管理员的工作流程。

添加新翻译组之前

完整的翻译组列表在 http://localize.drupal.org/ 上可以找到。所有语言包针对一种语言，内置了有区域代表性的 UI 和包含 l10n_groups（来自 l10n_server 模块）的有机群组。“Set up your group here!”（“在这里建立您的群组”）的区块解释了创建新语言包的首要步骤。添加新语言包的等待队列在 http://drupal.org/project/issues/localizedrupalorg?text=&status=Open&pri... 查看。

如果语言组已存在

如果语言组已存在，管理员须向重复申请此语言组的人指出并建议他/她加入已创建的语言组。大多数组是开放加入的（依据群组设置）。如果存在争议，另建一分组对用户不友善，将不被支持。

如果一语言为另一已有语言的分支

如果新建的语言组为另一语言组的分支，管理员须指出 localize.drupal.org 不支持从现有语言组继承翻译。翻译者可以手动由上一级所属语言导入，这需要重写自定义的翻译条目，或者留下一大堆很难整合到UI界面的翻译建议。
总之，会产生大量人工，而翻译者们不太乐意去做。
未来如果有解决方案，Localize.drupal.org 可能会支持基于外来语的翻译。请看 https://drupal.org/node/608488 。

如果语言组已有一个翻译服务器/（基于旧CVS的）d.o.翻译库

先检查一下是否已经进行了（部分）翻译。有些人可能等不及 drupal.org 的翻译服务器就自己运行了一个。如果已经作了部分翻译，最好不要再重复劳动、也尊重已完成的翻译工作。管理员如果不确定是否有已完成的翻译，应该经常询问翻译者。搜索语言名称和Drupal，查看是否有可疑的结果。

如果确定需要添加新语言组

思考以下问题：

• 是否已知已进行的翻译工作？（同上）
• 是否有其他人可以加入此翻译组工作？翻译Drupal并不轻松。
• 此语言的W3C语言标记语种代码是什么？我们必须使用标准的语种代码以便利网络上的Drupal共享和协作。更多信息请看 http://www.w3.org/International/articles/language-tags/，请使用 http://rishida.net/utils/subtags/ 核实此语种代码对W3C是否已知、是否正确。国家代码不能作为语种代码。
• 语种的复数公式是什么。（稍后将解释为什么需要知道这个）
  http://translate.sourceforge.net/wiki/l10n/pluralforms 这个页面列出了多种语言的复数公式，但也不是完全准确，请与新语言组建议者核实。

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

1. 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.
2. Add the language group on http://localize.drupal.org/node/add/l10n-group.
   1. The group name and description should be standard text like "Greek team" (if adding Greek).
   2. 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.
   3. Leave everything else as default, until you reach URL alias at close to the bottom.
   4. Set the URL alias to "languages/el" (where 'el' is the language code).
   5. Set the Group manager (in authoring information) to the group lead who applied to start out the team.
3. 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.
4. 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.