Help:Extension:Translate/Page translation administration/da

Hvad. Sideoversættelses-funktionen gør det muligt at styre oversættelse af wiki-sider til andre sprog. Det betyder, at indholdet af hver oversættelse vil være lig med kildesiden, sædvanligvis. Det gælder derimod f.eks. ikke de forskellige sprogversioner af Wikipedia-artikler, som er helt uafhængige af hinanden. Det antages, at siderne kun er oversat fra et primært sprog til andre sprog, men oversættere kan også drage fordel af oversættelser på andre sprog, hvis de findes.

Hvorfor. Uden hjælp, bliver oversættelse mere end et par sider til andre sprog i bedste fald en tidsrøver eller i værste fald ubehjælpeligt roderi. Med sideoversættelses-funktionen kan du undgå rodet og strukturere oversættelsesprocessen. Den centrale idé er opdeling af kildeteksten i mindre enheder, som hver især vil blive oversat individuelt. Når kildeteksten er opdelt i enheder, kan alle ændringer isoleres og oversættere behøver kun at opdatere oversættelsen af enheder, der har fået foretaget ændringer i kildeteksten. Dette muliggør for oversættere at arbejde på enheder af overskuelig størrelse og at dele arbejdet mellem forskellige oversættere og at fortsætte oversættelses-arbejdet senere, da det ikke behøves at gøres altsammen på én gang.

Hvem. Denne side uddyber hvordan man forbereder en side til oversættelse ved at give dybere indsigt i hvordan systemet fungerer og de bedste øvelser foreslås, med forskellige eksempler. Siden er beregnet til sideoversættelses-administratorer og generelt for enhver, der redigerer kildeteksten af sider, der kan oversættes, selv om de ikke har adgang til de administrative funktioner til godkendelse af ændringer af oversættelse. Udviklingsorienterede ting, herunder kendte problemer og fremtidige planer, dokumenteres på sideoversættelses-referencesiden.

Livsforløb for en side, der kan oversættes
Roller. Flere personer er involveret i processen med at skrive og oversætte en wiki side: den oprindelige forfatter opretter en side, nogen korrigerer stavefejl, en sideoversættelses-administrator markerer siden til oversættelse, oversættere oversætter, nogen laver ændringer på siden, en sideoversættelses-administrator markerer disse ændringer til oversættelse og oversættere opdaterer oversættelser. Disse roller kan overlappe mere eller mindre, men det overordnede ansvar for en problemfri oversættelse påhviler sideoversættelses-administratoren. Administratoren bestemmer, når siden er klar til oversættelse første gang, sikrer at inddelingen tjener et formål og godkender (eller korrigerer) ændringerne.

Forberedelse. For at få noget oversat er du nød til at skrive det først. Hvis du allerede har lavet en oversættelse uden Translate-udvidelsen, se nedenfor afsnittet om flytning af oversættelser. Hvis du vil have masser af oversættelse, som skal kunne laves hurtigt, er det afgørende at kildeteksten er trimmet og god. Inden en side mærkes for oversættelse, spørg en anden om at korrekturlæse den og om muligt få en sprog-specialist til at lave teksten mere klar og præcis. Vanskelig ordforråd og svært forståelige sætninger forhindrer mange frivillige oversættelser. Mærkning også kan give problemer for oversættere, men som oversættelses-administrator kan du undgå disse problemer, se afsnittet nedenfor om håndtering af mærkning. Naturligvis påtvinger de ændringer, du foretager i en oversættelses kildetekst, opdatering af alle eksisterende oversættelser, så det er bedre at vente indtil sidens indhold har stabiliseret sig. På den anden side sker ændringer ofte og systemet håndterer det godt, så tjek afsnittet om håndtering af ændringer, nedenfor.

Mærkning. Når teksten ellers er klar til oversættelse, kan alle markere delene klar til oversættelse ved at indpakke dem med &lt;translate> -mærker og tilføje &lt;languages />-bjælken til siden. Sidstnævnte tilføjer en liste over alle oversættelser af siden med færdiggørelses- og opdaterings-procenter. Der er ingen andre tegn på at oversættelserne eksisterer. Se nedenfor hvordan man faktisk udfører mærkningen. Systemet registrerer, når mærkningen er placeret på siden, der kan oversættes og siden får et link til at markere den klar til oversættelse. Systemet vil nægte at gemme, hvis du for eksempel har glemt at tilføje et afslutnings-mærke. Siden tilføjes også listen på Special:PageTranslation som klar til oversættelse.

Klargørelse. Efter mærkningen, klargør en oversættelses-administrator siden til oversættelse. Brugergrænsefladen er forklaret i hvordan man forbereder en side til oversættelse. Oversættelses-administratorens ansvar er at sikre, at opdelingen giver mening, og at mærkningen har været korrekt. Siden kan ommærkes, hvis den har ændret sig i mellemtiden. Se nedenfor hvordan ændringer foretages, så de forårsager færrest mulige forstyrrelser. Mærkningen af siden starter en baggrundsproces, der bruger MediaWiki's jobkø. Processen gennemgår hver oversættelses-side og regenererer den, så ændringer i sidens skabelon afspejles og forældede oversættelser markeres. Derimod opdateres oversættelses-brugergrænsefladen straks. Oversættelse af nye enheder fungerer muligvis ikke førend baggrunds-processen også har opdateret meddelelses-indekset.

Ændringer. Brugere kan fortsætte med at foretage ændringer til sidens kilde. Ændringerne vil være synlige for brugere, der ser siden på kildesproget, men oversættelser strider mod oversættelses-enhederne fået fra den sidste version af original-siden, som er blevet markeret til oversættelse: Oversættelses-siderne er rapporteret til at være 100% opdateret hvis alle oversættelses-enhederne er oversatte, selv om kildesiden har nye ændringer. Du kan nemt se om der er umarkerede ændringer, når du ser siden der kan oversættes på kildesproget: der er en notits øverst som siger, at du kan oversætte denne side og der er links til ændringer, hvis der er nogen.

Kildesprog. Der er også en oversættelses-side med sprogkoden på kildesproget: den indeholder ikke de ekstra mærker og anden mærkning relateret til side-oversættelsen, som anvendes i sidens kildetekst. Siden har ingen link fra brugergrænsefladen, men det er praktisk når du for eks. vil indsætte siden (typisk for skabeloner der kan oversættes) eller eksportere den.

Lukkede anmodninger om oversættelse. Nogle sider, der kan oversættes, har et indhold, som kun er interessant i en vis tidsperiode. For eksempel bekendtgørelser og regelmæssige statusopdateringer, ligesom Wikimedia's aktuelle begivenheder. Du kan holde disse sider sammen med oversættelser, men skjule dem fra oversættelsens brugergrænseflade. Dette forhindrer ikke yderligere oversættelser af siderne, men det reducerer stærkt risikoen for, at en bruger ved et uheld begynder at oversætte siden. Afskrækning og tilbagerulning sker fra Special:PageTranslation.

Prioritering af sprog. Du kan også definere en liste over sprog, som du specifikt ønsker oversættelser til og efterlades sprog-listen tom forstås det som at alle sprog er tilladt. Siden vil opføre sig som en afskrækkende side (se forrige afsnit) for de sprog der ikke er på den prioriterede liste, og når der oversættes til dem, vil oversætterne få en notits. Du kan også forhindre oversættelse til andre sprog, for eks. hvis oversættelser faktisk bruges andre steder, og du vil ikke være i stand til at bruge dem, bortset fra på enkelte sprog.

Gruppering. Det er muligt at gruppere relaterede sider sammen. Disse grupper arbejder ligesom alle de andre meddelelsesgrupper. De har deres egne statistikker og indeholder alle undergruppernes meddelelserne, i dette tilfælde sider som kan oversættes. Denne funktionalitet er i øjeblikket i Special:AggregateGroups. Sammensatte meddelelsesgrupper er som standard sammenfoldede i Special:LanguageStats.

Flytning. Du kan flytte de sider, der kan oversættes, ligesom andre sider kan. Ved flytningen kan du vælge, om du også vil flytte alle undersider, der ikke skal oversættes. Flytningen bruger et baggrunds-job til at flytte de mange relaterede sider. Mens flytningen er i gang, er det ikke muligt at oversætte siden. Færdiggørelsen anmærkes i sidens oversættelses-log.

Sletning. Ligesom flytning, er foregår adgang til sletning af en side der kan oversættes, fra det normale sted. Du kan enten slette hele siden, eller blot en af dens oversættelser. For at slette en oversættelse, skal du gå til oversættelses-siden og derefter få adgang til sletning. Som ved flytning, vil en baggrundsproces slette siderne over tid. Sletning vil også slette de relaterede oversættelsesenheds-sider. Færdiggørelse anmærkes i sidens oversættelses-log.

Beskyttelse. Det er muligt at beskytte siden, som kan oversættes. Oversættelses-sider kan ikke beskyttes og en beskyttelse af kildesiden dækker ikke her. For at forhindre yderligere redigeringer af oversættelser, bør du tilføje kildesproget som eneste prioriterede sprog og deaktivere oversættelser til andre sprog, se prioritering af sprog ovenfor. Tilsammen forhindrer disse to handlinger effektivt ændringer af både kildesiden og oversættelses-sider med sine oversættelsesenheds-sider. Det er muligt at beskytte individuelle oversættelsesenheds-sider, selv om det frarådes.

Fjernelse af oversættelse. Det er også muligt at fjerne en sides klargørelses-mærkning til oversættelse. Først skal du fjerne alle oversætter-mærker fra siden. Derefter kan du bruge Special:PageTranslation eller følg linket i toppen af siden der kan oversættes, for at fjerne det fra oversættelse. Dette vil fjerne enhver struktur relateret til side-oversættelse, men lad alle de eksisterende sider forblive frit redigerbare. Denne handling kan ikke anbefales.

Opbygning af en side der kan oversættes
Ved oversættelse af en side, der kan oversættes, produceres der mange sider, som tilsammen komponerer siden latu sensu, der også kan oversættes: deres titel bestemmes af titlen på den oprindelige :


 * (kilde side)
 * (oversættelses-siderne og en kopi af kildesiden uden mærkning)
 * (alle oversættelsesenheds-siderne)

Derudover er der oversættelsesside-skabelonen og kilderne til oversættelses-enhederne, udtrukket fra kildesiden og gemt i databasen. Systemet holder styr på, hvilke versioner af kildesiden indeholder oversættelses-mærker og hvilken version af dem er blevet markeret til oversættelse.

Hver gang en oversættelsesenheds-side er opdateret, vil systemet også regenerere den tilsvarende oversættelses-side. Dette vil resultere i to redigeringer. Oversættelsesenheds-side redigeringen er som standard skjult i seneste ændringer og kan vises ved at vælge vis oversættelser fra oversættelses-filteret. Andre handlinger end redigering af oversættelsesenheds-sider vil ikke udløse regenerering af den tilsvarende oversættelses-side.

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 trough 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>, but after &lt;nowiki>. If you want to have literal &lt;translate tag on the source, you must 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)


 * 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. There are some such templates available on the wikis which use the Translate extension, but they won't be dealt with here.

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> 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, you can avoid invalidating the existing translations: translators will still see the difference if they ever update the translation for any reason. If you change the meaning of the unit considerably, you may want to remove the unit marker to prevent outdated information in translations. In this case translators have to translate the message from scratch, although the translation memory can help them.

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, when the page is re-marked for translation, the old translations remain visible, but marked as outdated. The new unit will appear in source language and repeat the latter half of the old translation which would belong to the new unit. 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, it is recommended that you remove the unit markers. If you only kept the first unit marker, the translation page would not show the text of the latter unit until the translation would be updated.

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.