Help:Extension:Translate/Page translation administration/zh

'''什么. '''页面翻译功能支持把 wiki 页面翻译为其他语言. 意思是每种翻译的内容通常都等同于源页面. 与之不同的是，例如在不同的维基百科中，不同语言的条目内容完全是独立的. 一般假定为页面仅从一种主要语言翻译为其他语言，不过译者也可以利用其他存在的翻译.

'''为什么. '''如果不利用辅助工具，翻译大量页面到其他语言最好的情况也会成为耗时的事情，最糟糕时会变成无法管理的一团乱麻. 通过页面翻译功能，您可以避免混乱并在翻译过程中保持结构清晰. 核心方法是把源文本分割成更小的单元，在翻译时每个单元保持独立. 把源文本分割成单元后，所有的改变都是独立的，译者只需更新源文本有变化单元的译文. 同时也让译者可操作于可管理大小的单元或在后面的会话中继续，而不用一次性做完.

'''谁. '''页面翻译指南中通过深入的视角详细说明了系统工作的原理，并提供了适用于大部分情况的最佳实践的建议. 该页面提供给页面翻译管理员和编辑可译页面源文本的每个人，尽管后者无法访问批准翻译变化的管理功能.

翻译页面的生命力
'''角色. '''多人参与编写和翻译 wiki 页面的过程：最初有编者创建页面，有人纠正拼写错误，页面翻译管理员标记页面待翻译，译者翻译页面，有人修改了页面，翻译管理员标记这些修改为待译接着译者更新了译文. 这些角色多少有些重合，不过无争议翻译的根本责任在于页面翻译管理员. 他最开始决定页面是否适合翻译，确保片段分割合理及批准（或改正）变化.

'''预备. '''在翻译之前您必须编写内容. 如果您未使用翻译扩展就完成了翻译，请参阅下面的有关迁移翻译的段落. If you want lots of translation and quickly, it is crucial for the source text to be in good shape.在标记页面为待译前，让别人先校对过，如果可行则让语言专家把文本调整到更简洁清晰. 生涩的词汇和难懂的句子会给志愿者的翻译产生障碍. 标记也可能给译者带来问题，不过作为翻译管理员您可以去除这些问题，请参阅下面的有关标记处理的段落. 自然您对翻译的源内容的修改要求强制更新现有译文，所以最好等到页面内容稳定后再进行. 另一方面，改变已经发生了，系统能正常处理，因此请检查下面的有关处理变更的段落.

'''加标签. '''当文本已经适合翻译时，每个人都可以把需要翻译的部分括在 &lt;translate> 标签中并添加 &lt;languages /> 栏到页面. 后者在页面中增加了当前页面的所有译文列表及翻译完成百分率. 这是表示存在译文的唯一提示. 请参阅下面的加标记的具体方法. 系统能检测到在可译页面包含的标签，且该页将会出现待译标记. 如果您忘记加上闭标签或类似问题，它还会提示并无法保存. 可译页面还会列出于 Special:PageTranslation 的等待标记部分.

'''标记. '''添加标签后，翻译管理员标记页面为待译状态. 其界面的说明在页面翻译示例. 翻译管理员的职责是确保分割合理、所加标签合适. 如果在这期间内容改变了可以再次标记该页. 请参阅下面的如何标记变化才能减小分裂. 页面的标记开启了使用 MediaWiki 作业队列的后台进程. 该进程扫描每个翻译页面并重新生成：反映出翻译页面模板的变化并把过时翻译临时替换为源文本. 反之，立即更新翻译界面.

'''变更. '''用户可以继续修改源页面的内容. 在查看源语言页面时可以看到该变更，从标记为翻译的可译页面最新版本中提取了翻译单元后翻译页面中也可以看到：如果翻译了所有单元则会提示 100%，即使此时源页面发生了新变更. 查看源语言的可译页面时您可以很容易看到未标记的变更：在页面靠上的位置会显示通告提示您可以翻译本页及链接到包含的变更.

源语言. 还有个含源语言代码的翻译页面，不过这种翻译页面不包含附加标记和其他可译的源页面中使用的翻译相关标记. 它不会链接到翻译界面，不过在转置（通常用于可译模板）或导出页面时很方便.

'''封闭的翻译请求. '''一些可译页面的内容只在某段时间中有意义，例如通告和周期性的状态更新（如维基媒体每月亮点）. 您可以让这些页面包含翻译，但从翻译界面中隐藏它们. 这样不会阻止这些页面之后进行翻译，不过极大降低了用户偶然翻译它们的机会. Discouraging and its reversion are done from Special:PageTranslation.

Prioritizing languages. You can also define a list of languages that you specifically want translations into; leaving the language list empty is interpreted as all languages allowed. The page will behave like a discouraged page (see previous paragraph) for the languages not in the priority list and, when translating into them, translators will be given a notice. You can also prevent the translation in other languages, say if translations are actually used elsewhere and you won't be able to use them but in some languages.

Grouping. It is possible to group related pages together. These groups work like all the other message groups. They have their own statistics and contain all the messages of the subgroups: in this case translatable pages. This functionality is currently in Special:AggregateGroups. Aggregate message groups are collapsed by default in Special:LanguageStats in the group selector at Special:Translate.

Moving. You can move translatable pages as you would move any other page. When moving you can choose whether you want to move any non-translation subpages too. The move uses a background job to move the many related pages. While the move is in progress, it is not possible to translate the page. Completion is noted in the page translation log.

Deleting. Like move, deletion is accessed from the normal place. You can either delete the whole translatable page, or just one translation of it. To delete one translation, go to the translation page and then access delete. As in move, a background process will delete the pages over time. Deletion will also delete the related translation unit pages. Completion is noted in the page translation log.

Reverting. Similarly, reverting incorrect edits works as usual (including rollback button): you only have to edit the affected translation unit and the translation page will be updated as well. To find the edit to the translation unit from the edit to the translation page, just click the "" link for the editor and look for an edit at a similar time.

Protecting. It is possible to protect the translatable page. Translation pages cannot be protected, nor does the protection of the translatable page extend to them. To prevent further edits to translations, you should add the source language as only priority language and disable translations to other languages, see prioritizing languages above. Together these two actions effectively prevent changes to both the source page and translation pages with its translation unit pages. It is possible to protect individual translation unit pages, though it is not advisable.

Removal from translation. It is also possible to unmark a page for translation. First you need to remove all translate tags from the page. Then you can use Special:PageTranslation or follow the link in the top of translatable page to remove it from translation. This will remove any structure related to page translation, but leave all the existing pages in place, freely editable. This action is not recommended.

翻译页面的拆分
翻译可翻译页面会产生许多页面，它们像latu sensu一样组成翻译页面的：他们的标题取决于翻译的页面 ：


 * （源页面）
 * （翻译页面，加上没有嵌入部分的源页面）
 * （所有翻译单元页）

In addition to this, there are the translation page template and the sources of translation units, extracted from the source page and stored in the database. The system keeps track of which versions of the source page contain translation tags and which version of them have been marked for translation.

Every time a translation unit page is updated, the system will also regenerate the corresponding translation page. This will result in two edits. The translation unit page edit is hidden by default in recent changes and can be shown by choosing show translations from the translation filter. Any action other than editing (like deleting and moving) the translation unit pages will not trigger the regeneration of the corresponding translation page.

分割
一般原则：


 * 1) 所有要翻译的文本必须在翻译标记内. 一个页面可以有许多对翻译标记.
 * 2) 这些标记外的所有内容在任何翻译页面中都保持一致. 这些静态文本及标记每个翻译单元替换位置的占位符被称为翻译页面模板.
 * 3) 太多的嵌入项会使译者很难翻译. 请使用更多放置良好的翻译标签来移除嵌入项.
 * 4) 带有翻译标签的文字会被分割成翻译单元，它们之间会有一或多个空行（两个或更多新行符）.

Restrictions. The page translation feature places some restrictions on the text. There should not be any markup that spans over two or more translation units. In other words, each paragraph should be self-contained. This is currently not enforced in the software, but violating it will cause invalid rendering of the page, the severity depending on whether MediaWiki itself is able to fix the resulting html output or not.

Parsing order. Beware, the translate tags work differently from other tags, because they do not go through the parser. This should not cause problems usually, but may if you are trying something fancy. In more detail, they are parsed before any other tags like &lt;pre> or &lt;source>, with the exception of &lt;nowiki> which is recognized by the Translate extension in some circumstances (such as rendering a page) but not in others (such as generating the list on Special:PageTranslation of pages containing &lt;translate>). If you want to have the literal expression "&lt;translate>" in the source text, you should escape it like "&amp;lt;translate>".

Tag placing. If possible, try to put the tags on their own lines, with no empty lines between the content and the tags. Sometimes this is not possible, for example if you want to translate some content surrounded by the markup, but not the markup itself. This is fine too, for example:

To make this work, the extension has a simple whitespace handling: whitespace is preserved, except if an opening or closing translate tag is the only thing on a line. In that case the newline after the opening tag or before the closing tag is eaten. This means that they don't cause extra space in the rendered version of the page.

Variables. It is possible to use variables similar to template variables. The syntax for this is. For translators these will show up only as, and in translation pages will automatically be replaced by the value defined in the translatable page (so they are global "constants" across all its translation pages). Variables can be used to hide untranslatable content in the middle of a translation unit. It also works for things like numbers that need to be updated often. You can update the number in all translations by changing the number in the translatable page source and re-marking the page. You do not need to invalidate translations, because the number is not part of the translation unit pages.

嵌入部分示例
下面列出一些处理这些嵌入的wiki元素的可选方法和建议.

{| class=wikitable 不翻译: Category:Cars
 * 分类
 * Categories can be added in two ways: in the translation page template or in one of the translation units. If you have the categories in the translation page template, all translations will end up in the same category. If you have categories inside translation units, you should teach the users a naming scheme. On the right we show two possible schemes which are independent of the technical means to adopt them.


 * 所有译文划归一分类（如果只有少量语言的话很好，但有很多语言时就不是很合适）.
 * 分类名称不要翻译（可以像模板一样原样放置）.

通过添加后缀翻译：Category:Cars/fi (推荐但不支持)

There are some such templates available on the wikis which use the Translate extension, but they won't be dealt with here. Additionally, categories' description pages will have to be created manually and translated with a non-Translate system, because the extension is not able to deal with them.
 * 分类页面不名称不翻译（就像页面名称）.
 * 每个语音都使用一个分类.
 * Page translation could be used for the category itself: the categories would be linked together and the headers would be translated (but not the name of the category in links and such).
 * This option is not yet supported out of the box by the Translate extension. You need to either instruct your translators to add the language code suffix to the category markup in the translation, or leave the category out of translation and write your own templates which add the language code automatically.

错误： == &lt;translate>Culture&lt;/translate> ==
 * 大标题
 * Headers can in principle be tied to the following paragraph, but it is better to have them separated. This way someone can quickly translate the table of contents before going into the contents. When tagging headers, it is important to include the header markup inside the tags, or MediaWiki will no longer identify them properly, for example when trying to edit a specific section of the source page. The markup also immediately gives translator a context: he/she is translating a header.
 * Headers can in principle be tied to the following paragraph, but it is better to have them separated. This way someone can quickly translate the table of contents before going into the contents. When tagging headers, it is important to include the header markup inside the tags, or MediaWiki will no longer identify them properly, for example when trying to edit a specific section of the source page. The markup also immediately gives translator a context: he/she is translating a header.

正确： &lt;translate>== Culture ==&lt;/translate> 推荐分割： &lt;translate>

Culture
Lorem ipsum dolor. &lt;/translate>

&lt;translate> &lt;/translate>
 * 图片
 * Images that do contain language specific content like text should include the full image syntax in an unit. Other images can only tag the description with optional hint in message documentation of the page after it has been marked.
 * Images that do contain language specific content like text should include the full image syntax in an unit. Other images can only tag the description with optional hint in message documentation of the page after it has been marked.


 * 链接
 * Links can be included in the paragraph they are inside. This allows changing the link label, but also changing the link target to a localized version if one exists.
 * Links can be included in the paragraph they are inside. This allows changing the link label, but also changing the link target to a localized version if one exists.

If the target page is (or should be) also translatable, you should link to it by prepending  to its title. Only the link label will need to be translated, because this automatically redirects users to the translation page in their own interface language, as selected for instance via the UniversalLanguageSelector. However, to achieve a constant behavior the syntax must be used for all links.

Because headers are translated, you cannot rely on the automatically generated id's for headers. You can add your own anchors. To have them outside of the translation template you need to break up the page into multiple translate tag pairs around each header you want to have an anchor to. 内部链接： &lt;translate> Helsinki is capital of Finland. &lt;/translate>

链接至翻译页面 &lt;translate> It has marvelous beaches with a lot of seagulls. &lt;/translate> 外部链接： &lt;translate> PHP (website) is a programming language. &lt;/translate> 页面中的链接： &lt;translate>

Culture
Lorem ipsum dolor.

...

For more about food, see section about culture. &lt;/translate>

&lt;translate> &lt;translate> &lt;/translate>
 * 列表
 * Lists can get long, so might want to split them into multiple parts with for example five items or less in each as follows. Do so only if the items are sufficiently independent to be translate separately in all languages, don't create "lego messages": for instance, you must avoid to split a single sentence in multiple units, or to separate logically dependent parts which may affect each other (with regard to punctuation or style of the list, for instance). To split a list, use -tags. Do not insert new lines as this will break the HTML output.
 * Lists can get long, so might want to split them into multiple parts with for example five items or less in each as follows. Do so only if the items are sufficiently independent to be translate separately in all languages, don't create "lego messages": for instance, you must avoid to split a single sentence in multiple units, or to separate logically dependent parts which may affect each other (with regard to punctuation or style of the list, for instance). To split a list, use -tags. Do not insert new lines as this will break the HTML output.
 * General principles
 * Headings
 * Images
 * Tables
 * Categories&lt;/translate>
 * Links
 * Templates


 * 数字
 * With numbers and other non-linguistic elements you may want to pull the actual number out of translation and make it a variable. This has multiple benefits:
 * With numbers and other non-linguistic elements you may want to pull the actual number out of translation and make it a variable. This has multiple benefits:

&lt;translate> Income this month  EUR &lt;translate> Note that this prevents the translators from localising the number by doing currency conversion. The  call makes sure the number is formatted correctly in the target language.
 * 你可以更新这些数据为不可翻译.
 * 翻译记忆会忽略这些数据变化.


 * 模板
 * Templates have varying functions and purposes, so the best solution depends on what the template is for. If the template is not a part of longer paragraph, it should be left out, unless it has parameters that need to be translated. If the template has no linguistic content itself, you don't need to do anything for the template itself.
 * For an example of templates translated with page translation, see Template:Extension-Translate. To use this template, you need to have another template similar to Template:Translatable navigation template, because you cannot include the template by anymore. This is not yet provided by the Translate extension itself, but that is in the plans.
 * For an example of templates translated with page translation, see Template:Extension-Translate. To use this template, you need to have another template similar to Template:Translatable navigation template, because you cannot include the template by anymore. This is not yet provided by the Translate extension itself, but that is in the plans.

Another way is to use the unstructured element translation to translate the template, but then the language of the template will follow the user's interface language, not the language of the page he is viewing.
 * }

更改源文本
一般原则：


 * 避免更改
 * 变动尽可能的独立
 * 不要人为添加翻译单元标记

Unit markers. When page is marked for translation, the system will update the translatable page source and add unique identifiers for each translation unit. See example below. These markers are crucial for the system, which uses them to track changes to each translation unit. You should never add unit markers yourself. The markers are always on the line before the unit; or, if it starts with a header, after the first header on the same line. The different placement for headers is needed to keep section editing working as expected.

&lt;translate>

Birds
&lt;!--T:1--> Birds are animals which....

&lt;!--T:2--> Birds can fly and... &lt;/translate> Changing unit text. Changing is the most common operation for translation units. You can fix spelling mistakes, correct grammar or do other changes to the unit. When re-marking the page for translation, you will see the difference in the unit text. The same difference is also shown to translators when they update their translations. For simple spelling fixes and other cases where you don't want the existing translations to be removed from translation pages, you can avoid invalidating them: translators will still see the difference if they ever update the translation for any reason.

Adding new text. You can freely add new text inside translate tags. Make sure that there is one empty line between adjacent units, so that the system will see it as a new unit. You can also add translate tags around the new text, if it is not inside existing translate tags. Again, do not add unit markers yourself, the system will do it.

'''删除文本. ''' 你可以删除整个翻译单元，但请同时删除翻译单元标记.

Splitting units. You can split existing units by adding an empty line in the middle of a unit, or by placing translate tags so that they split the unit. You can either keep the unit marker with the first unit or remove it altogether. In the first case, translators see the old text when updating the old translation. If you removed the unit marker, both units will behave as if no translation ever existed, after the page is re-marked for translation.

移动翻译单元 如果你要移动翻译单元，你可以移除所有内容但至少应移除一个翻译标记.

Moving units. You can move units around without invalidating translations: just move the unit marker together with the rest of the unit.

Before marking the new version of the page for translation, ensure that the best practices are followed, especially that translators get a new translation unit if the content has changed. Also make sure that there are no unnecessary changes to prevent wasting translators time. If the source page is getting many changes, it may be worthwhile to wait for it to stabilize, and push the work for translators only after that.

Unused unit translations are not deleted automatically, but that should not cause trouble.

移动翻译页面
If you have been translating pages before using the page translation system, you might want to migrate the pages to the new system, at least the ones you expect to have new translations and want statistics for. You will probably have existing templates for language switching and maybe different page naming conventions.

You can start migration by cleaning up, tagging and marking the source page. You can keep the existing language-switching templates while you migrate the old translations. If your pages follow the language code subpages naming convention, they will be replaced with the source text after marking the source page for translation, but you'll still be able to access translations from history.

This is manual work, where you have to open the old translation page and copy and paste translations from there to correct translation units in the new system using the translation interface. For this you need to roughly know which part of the translation matches which part of the old text (and hope they match). You might want to consider marking all the migrated translations as needing update by prepending the string  to the translations and have a translator look at them. Once migrated, you can delete the old translation pages if they are not using the same naming convention (or you could have switched them to it before migration). Once all pages are migrated you can also remove old language navigation templates.