Help:Extension:Translate/Page translation administration/uk

Що. Функція перекладу сторінок дозволяє контрольований переклад вікісторінок іншими мовами. Це означає, що вміст кожного перекладу буде зазвичай ідентичний оригінальній сторінці. Це відрізняється від, наприклад, інших мовних версій статей у різних Вікіпедіях, які повністю незалежні одна від одної. Передбачається, що сторінки перекладаються лише з одної основної мови на інші, але перекладачі можуть скористатися перекладами іншими мовами, якщо вони існують.

Чому. Без жодної допомоги, перекладання більш ніж кількох сторінок іншими мовами стає в кращому випадку убиванням часу, в гіршому — марне казна-що. З функцією перекладу сторінок ви можете уникнути безладу і внести структурованість у процес перекладу. Ключова ідея полягає у тому, що вихідний текст поділяється на менші шматки, кожен з яких можна перекласти окремо. Коли вихідних текст сегментований, усі зміни можуть бути розмежовані і перекладачам просто треба оновити переклад тих частин, у вихідному тексті яких стались зміни. Це також дає змогу перекладачам працювати з блоком посильного розміру і ділити роботу між кількома людьми або продовжувати переклад іншим разом, оскільки їм не треба робити усе одразу.

Хто. Ця сторінка детальніше розвиває посібник з перекладу сторінок, показуючи глибше бачення того, як працює система, і пропонує кращі рішення для широкого спектру випадків. Ця сторінка призначена для адміністраторів перекладу і загалом усіх, хто редагує вихідний текст перекладабельних сторінок, навіть якщо у них немає доступу до адміністраторських функцій позначення змін для перекладу.

Життя перекладабельної сторінки
Ролі. Численні люди задіяні у процесі написання і перекладу вікісторінки: початковий автор створює сторінку, хтось виправляє орфографічні помилки, адміністратор перекладу позначає сторінку на переклад, перекладачі перекладають, хтось вносить зміни на сторінки, адміністратор перекладу позначає ці зміни на переклад, а перекладачі оновлюють переклади. Ці ролі можуть накладатися більше чи менше, але кінцева відповідальність за безпроблемний переклад лежить на адміністраторі перекладу. Адміністратор вирішує, коли сторінка готова для першого перекладу, перевіряє, щоб поділ на блоки відповідав цілям і підтверджує (або виправляє) зміни.

Підготовка. Щоб щось було перекладено, це щось спершу треба написати. Якщо у вас уже зробили переклад, не використовуючи розширення Translate, див. нижче розділ про міграцію перекладів. Якщо переклад потрібен великий і швидко, дуже важливо, щоб вихідний текст був у гарній формі. До того, як позначати сторінку на переклад, попросіть когось вичитати його і, якщо це можливо, попросіть спеціаліста-мовника зробити його більш чітким і зрозумілим. Складні слова і незрозумілі речення стають перешкодою для багатьох волонтерських перекладів. Вікірозмітка також може викликати проблеми у перекладачів, але як адміністратор перекладу, ви можете уникнути цих складнощів, див. розділ про поводження з вікірозміткою. Зміни, які ви робите у вихідному тексті, спричиняють оновлення усіх існуючих перекладів, тому краще почекати, поки вміст сторінки стабілізується. З іншого боку, зміни трапляються, і система з ними справляється, тому перегляньте нижче розділ про поводження зі змінами.

Теґування. Коли текст готовий до перекладу, будь-хто може позначити частини, що можуть бути перекладені, взявши їх у теґи &lt;translate> і додавши на сторінку панель &lt;languages />. Остання додає список усіх перекладів сторінки, з відсотками їх завершеності і актуальності. Іншої вказівки на існуючі переклади немає. Див. нижче, як, власне, робиться теґування. Система виявить, що на сторінку було додано теґи, і на ній з'явиться посилання на позначення її на переклад. Вона також сповістить і не дозволить зберегти сторінку, якщо ви, наприклад, забули додати закриваючий теґ. Перекладабельна сторінка також буде у списку на Special:PageTranslation як готова до позначення.

Позначення. Після теґування, адміністратор перекладу позначає сторінку для перекладу. Інтерфейс пояснено на сторінці Приклад перекладу сторінки. Обов'язок адміністратора перекладу переконатись, що сегментування логічне і що теґування зроблене правильно. Сторінка може бути позначена знову, якщо її між тим було змінено. Див. нижче як робити зміни, що спричиняють мінімальні збої. Позначення сторінки запускає фоновий процес, що використовує чергу задач MediaWiki. Цей процес проходить по кожній сторінці перекладу і регенерує її: зміни у шаблоні сторінки перекладу відобразяться і застарілі переклади будуть тимчасово замінені вихідним текстом. Навпаки, перекладацький інтерфейс оновлюється автоматично.

Зміни. Користувачі можуть продовжувати робити зміни у вікітексті перекладабельної сторінки. Зміни будуть видимими для користувачів, що переглядають її вихідною мовою, але переклади зроблені щодо блоків перекладу останньої версії перекладабельної сторінки, що була позначена на переклад: сторінки перекладу будуть відображатись як 100% актуальні, якщо перекладені усі блоки, навіть якщо вихідна сторінка містить нові зміни. Ви легко можете побачити, чи є непозначені зміни, коли переглядаєте перекладабельну сторінку вихідною мовою: у верхній частині є сповіщення, у якому сказано, що ви можете перекладати цю сторінку, і є посилання на зміни, якщо такі були.

Вихідна мова. Також є сторінка перекладу з мовним кодом вихідної мови: вона не містить додаткових теґів та іншої вікірозмітки, що стосується перекладу сторінки, які використані у початковій перекладабельній сторінці. На цю сторінку немає посилань з інтерфейсу, але вона зручна, якщо ви, наприклад, хочете зробити її включення (зазвичай для перекладабельних шаблонів) або експортувати її.

Закриті запити на переклад. Деякі перекладабельні сторінки містять контент, цікавий лише певний період часу. Наприклад, оголошення і регулярні оновлення, як-от щомісячні новини Вікіпедіа. Ви можете тримати ці сторінки під рукою з перекладами, але приховати їх з перекладацького інтерфейсу. Це не відверне подальші переклади, але значно зменшить шанс того, що користувач випадково почне перекладати цю сторінку. Знеохочення і його відміна робляться на Special:PageTranslation.

Встановлення пріоритетних мов. Ви можете також встановити список мов, переклади на які особливо потрібні; якщо список мов залишити пустим, це означатиме, що дозволені усі мови. Сторінка поводитиметься як знеохочена (див. попередній абзац) для мов, які не вказані у списку пріоритетних, і під час перекладу ними, перекладачі побачать сповіщення. Ви також можете запобігти перекладу іншими мовами, say if translations are actually used elsewhere and you won't be able to use them but in some languages.

Групування. Є можливість групувати пов'язані між собою сторінки. Ці групи працюють як і всі інші групи повідомлень. Вони мають свою статистику і містять усі повідомлення із підгруп: у цьому випадку — перекладабельних сторінок. Цей функціонал зараз на Special:AggregateGroups. Агреговані групи повідомлень за замовчуванням згорнуті на Special:LanguageStats у виборі груп на Special:Translate.

Перейменування. Ви можете перейменовувати перекладабельні сторінки так само, як би ви це робили з будь-якою іншою сторінкою. При перейменуванні ви можете вказати, чи бажаєте перейменувати також кожну неперекладну сторінку. Перейменування використовує фонову задачу для перейменування багатьох пов'язаних сторінок. Поки іде процес перейменування, сторінку перекладати не можна. Його завершення відмічається у журналі перекладу сторінки.

Вилучення. Як і перейменування, вилучення здійснюється у звичному місці. Ви можете вилучити або усю перекладабельну сторінку, або лише один її переклад. Щоб вилучити один переклад, перейдіть на сторінку перекладу і потім вилучіть його. Як і з перейменуванням, фоновий процес вилучить сторінки з часом. Вилучення також видалить пов'язані сторінки блоків перекладу. Завершення буде відмічене у журналі перекладу сторінки.

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.

Anatomy of a translatable page
The translation of a translatable page will produce many pages, which all together compose the translatable page latu sensu: their title is determined by the title of the translatable :


 * (the source page)
 * (the translation pages, plus a copy of the source page without markup)
 * (all the translation unit pages)

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.

Segmentation
General principles:


 * 1) All text intended for translation must be wrapped inside translate tags. There can be multiple pairs of tags in one page.
 * 2) Everything outside those tags will not change in any translation page. This static text, together with the placeholders which mark the place where the translation of each translation unit will be substituted, is called the translation page template.
 * 3) Too much markup in the text makes it difficult for translators to translate. Use more fine grained placing of translate tags when there are lots of markup.
 * 4) The text inside translate tags is split into translation units where there is one or more empty lines between them (two or more newlines).

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 &lt;tvar|name>contents. 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.

Markup examples
Below are listed some alternatives and suggested ways to handle different kinds of wiki markup.

{| class=wikitable No translation: Category:Cars
 * Categories
 * 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.


 * All translations in same category (good if only few languages, bad if many).
 * Category name not translated (can be put as is in the translation template).

Translation by adding language suffix: Category:Cars/fi (recommended but unsupported)

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.
 * Category page name not translated (just like the page names).
 * One category for each language.
 * 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.

Wrong: == &lt;translate>Culture&lt;/translate> ==
 * Headers
 * 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.

Correct: &lt;translate>== Culture ==&lt;/translate> Suggested segmentation: &lt;translate>

Culture
Lorem ipsum dolor. &lt;/translate>

&lt;translate> &lt;/translate>
 * Images
 * 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
 * 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.

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. Internal links: &lt;translate> Helsinki is capital of Finland. &lt;/translate> External links: &lt;translate> PHP (website) is a programming language. &lt;/translate> Links within a page: &lt;translate>

Culture
Lorem ipsum dolor.

...

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

&lt;translate> &lt;/translate>&lt;translate> &lt;/translate>
 * Lists
 * 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).
 * 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).
 * General principles
 * Headings
 * Images
 * Tables
 * Categories
 * Links
 * Templates


 * Numbers
 * 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 &lt;tvar|income>3,567,800 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.
 * You can update the number without invalidating translations.
 * Translation memory can work better when the changing number is ignored.


 * Templates
 * 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.
 * }

Changing the source text
General principles:


 * Avoid changes
 * Make the changes as isolated as possible
 * Do not add translation unit markers yourself

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.

Deleting text. You can delete whole units. If you do so, also remove the unit marker.

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, translations 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.

Merging units. If you merge units, you have to remove at least all but one unit marker.

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.

Migrating to page translation
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 !!FUZZY!! 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.