Der Versionsimport (auch „Importupload“ oder XML-Import genannt) ist eine Methode, Wikipedia-Artikel von einem Schwesterprojekt ins andere zu importieren oder innerhalb eines Projektes zu duplizieren. Er wird hauptsächlich angewandt, um bei Weiterverwendung der importierten Inhalte den urheberrechtlichen und lizenzmäßigen Ansprüchen der Ersteller der ursprünglichen Artikel genüge zu tun. In einfachen Fällen kann man diesen Ansprüchen genügen, indem Administratoren über das auf der Seite WP:Importwünsche zur Verfügung gestellte „automatische“ Import-Tool die kompletten Artikel samt Versionsgeschichte importieren (eine in geringem Umfang konfigurierbare Version des Import-Tools befindet sich hier, eine Anleitung dazu hier). Dies trifft jedoch in einigen Fällen auf technische und inhaltliche Grenzen, die ein komplexeres Vorgehen notwendig machen, eben den Versionsimport. Dies geschieht insbesondere dann,
- wenn ein Artikel über 1000 Versionen hat,
- wenn ein Artikel mitsamt seinen Vor-Versionen einen Umfang von mehr als 100 MB hat,
- wenn ein Artikel aus einem Projekt importiert werden soll, das nicht zu der hier aufgeführten abschließenden Liste gehört oder
- wenn ein Zielartikel zum Zeitpunkt des geplanten Importes bereits existiert und die Versionsgeschichten beider Artikel sich überlappen.
In diesen Fällen muß der Importvorgang in zwei oder gegebenenfalls drei Schritte aufgeteilt werden:
- Export des Quellartikels,
- gegebenenfalls zwischenzeitliche Manipulation des Quellartikels,
- Importupload des (ggflls. veränderten) Artikels
Um einen Importupload durchführen zu können, muß man die erweiterten Benutzerrechte als Importeur haben.
Grundlagen
BearbeitenUm das Vorgehen zu verstehen, ist es notwendig, die Art und Weise zu kennen, wie Wikipedia-Artikel überhaupt gespeichert sind. Jeder aktuelle Wikipedia-Artikel mitsamt seiner Vor-Versionen liegt in Form einer gemeinsamen XML-Datei vor. Der Aufbau dieser Datei ist immer gleich:
- Das Wurzelelement trägt die Bezeichnung „<mediawiki>“
- Das erste Element innerhalb des Wurzelementes trägt die Bezeichnung „<siteinfo>“ und beschreibt das Wiki, in dem der Artikel existiert, mit Elementen wie „<sitename>“, „<dbname>“, Aufzählungen der Namensräume etc.
- Als zweites und letztes Element innerhalb des Wurzelelementes schließt sich das Element „<page>“ an, das den eigentlichen Artikel und seine Versionen enthält. Zunächst wird mit drei Elementen namens „<title>“, <namespace> und <id> der Titel, der Namensraum und die ID-Nummer des Artikels angegeben. Auf diese drei Elemente folgen innerhalb des Elementes „<page>“ ein oder mehrere weitere Elemente namens „<revision>“, die die einzelnen Versionen des Artikels enthalten, beginnend mit der ältesten. Innerhalb des Elementes „<revision>“ folgen Versions-ID, Erstellungsdatum, Angaben zum Autor, ein paar technische Informationen, schließlich der Text der Version und ein Hash-Code.
Dieser Artikel beispielsweise sieht daher in seiner Quelldatei so aus:
<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.10/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.10/ http://www.mediawiki.org/xml/export-0.10.xsd" version="0.10" xml:lang="de">
<siteinfo>
<sitename>Wikipedia</sitename>
<dbname>dewiki</dbname>
<base>https://de.wikipedia.org/wiki/Wikipedia:Hauptseite</base>
<generator>MediaWiki 1.38.0-wmf.23</generator>
<case>first-letter</case>
<namespaces>
[...]
</namespaces>
</siteinfo>
<page>
<title>Wikipedia:Importwünsche/Versionsimport</title>
<ns>4</ns>
<id>12152327</id>
<revision>
<id>220741902</id>
<timestamp>2022-03-03T08:16:35Z</timestamp>
<contributor>
<username>M.ottenbruch</username>
<id>17301</id>
</contributor>
<comment>Beginn einer neuen Anleitung</comment>
<model>wikitext</model>
<format>text/x-wiki</format>
<text bytes="1864" xml:space="preserve">Der '''Versionsimport''' ist eine Methode, Wikipedia-Artikel, von einem Schwesterprojekt ins andere zu importieren [...] </text>
<sha1>7g1u5hcd448e3wam7nfuaa04u7bzekm</sha1>
</revision>
<revision>
[...]
</revision>
[...]
</page>
</mediawiki>
Hat man diese Datei einmal aus dem Quellwiki exportiert (siehe unten) und auf den Rechner heruntergeladen, kann man sie auf vielfältige Weise manipulieren. Insbesondere kann man
- Versionen entfernen, indem man schlicht „<revision>“-Elemente aus dem Quelltext löscht, und
- eine XML-Datei in mehrere kleinere aufteilen, wenn die oben genannte Obergrenze von 100 MB überschritten ist.
Das alles bzw. der nachfolgende Import geht nur dann, wenn die Datei weiterhin wohlgeformt und mit der Wikimedia-Software kompatibel ist, d.h. der oben beschriebene Aufbau muß grundsätzlich beibehalten werden; insbesondere muß das Wurzelelement erhalten bleiben, es muß weiterhin ein „<siteinfo>“- und ein „<page>“-Element enthalten sein, wobei Letzteres mindestens ein „<revision>“-Element enthalten muß. Beispielsweise der isolierte Import von einzelnen „<revision>“-Elementen in bestehende Quelldateien ist nicht vorgesehen.
Praktisches Vorgehen
BearbeitenExport der XML-Datei
BearbeitenAus der de-wp
BearbeitenAus der de-wp kann dieser Export in einfachen Fällen über das Tool auf der Seite Spezial:Exportieren erfolgen. Dazu sind nicht einmal Administratoren-Rechte erforderlich. Dieses Tool stößt jedoch an die oben genannte Grenze von 1000 Versionen.
Der einfachste Weg, diese Beschränkung zu umgehen, besteht darin, die Zeile
mw.loader.load('//de.wikipedia.org/w/index.php?title=Benutzer:Brackenheim/export.js&action=raw&ctype=text/javascript'); // [[Benutzer:Brackenheim/export.js]]
in die eigene common.js-Datei einzufügen.
Dies sorgt dafür, dass ein zusätzlicher, mit „export“ beschrifteter Reiter oder Button (je nach verwendetem Skin) eingeblendet wird, durch den man mit einfachem Klick einen Export des gerade angezeigten Artikels auf den eigenen Rechner anstoßen kann.
Der JavaScript-Code des durch diese Zeile eingebundenen Skriptes findet sich unter Benutzer:Brackenheim/export.js. Bei technischem Interesse ist ein Blick in die Versionsgeschichte und auf die Diskseite empfehlenswert.
Aus Schwesterprojekten
Bearbeiten-
Menüpunkt „Einstellungen/Aussehen“ mit markiertem Link auf commons.js
-
Menüpunkt „Globale Einstellungen“ mit markiertem Link auf „Sprache der Benutzeroberfläche:“
In aller Regel möchte man sich als Importeur nicht darauf beschränken, nur Artikel aus der de-wp zu exportieren. In einigen Schwesterprojekten existieren unserem Spezial:Exportieren vergleichbare Seiten, jedoch nicht in allen (im Zweifelsfall ist es hilfreich, im Schwesterprojekt „Special:export“ aufzurufen – oft ist das eine Weiterleitung auf die gesuchte Seite). Dann ist das durch die oben genannte Zeile hinzugeladene Tool ebenfalls hilfreich. In der aktuellen Version (seit 29. März 2023) ist das Skript ohne Veränderung des Quellcodes in allen Schwesterprojekten lauffähig.
Sofern man diese Möglichkeit nur in bestimmten Projekten nutzen möchte – bsplsw. weil man nur aus Projekten importieren möchten, deren Sprache man versteht und/oder deren Schrift man wenigstens lesen kann –, kann man das Skript in diesen Projekten durch die Einbindung der oben angegebenen JavaScript-Zeile in seine dortige commons.js dort für sich zugänglich machen.
Für exotischere Sprachversionen empfiehlt es sich – falls noch nicht geschehen – zunächst im Menüpunkt „Globale Einstellungen“ unter „Sprache der Benutzeroberfläche:“ die Benutzerführung für alle internationalen Versionen auf „de-Deutsch“ einzustellen, damit man den dortigen Menüpunkt „Einstellungen/Aussehen“, in dem die commons.js geändert werden kann (Abschnitt: „Gemeinsames CSS/JSON/JavaScript aller Benutzeroberflächen:“, Link: „Benutzerdefiniertes JavaScript“), gegebenenfalls überhaupt findet.
Wenn man in allen Schwesterprojekten dieses Feature nutzen möchte, kann man das Skript über die angegebene Zeile in seiner global.js auf Meta-Wiki einbinden.
Mögliche Probleme beim Export
BearbeitenBei übergroßen Quelldateien (mehrere 100 MB) stößt auch dieses Export-Tool auf Probleme. Es ist möglich, daß der Export vorzeitig, aber ohne Fehlermeldung abbricht. Man erkennt dies daran, dass nicht alle Versionen exportiert wurden und insbesondere am Dateiende die XML-Tags „“ und „ </page>
</mediawiki>
“ fehlen. In dieser Situation ist es meiner Erfahrung nach sinnvoll, den Export einfach noch einmal anzustoßen. Der exportierte Teil der Quelldatei wird bei jedem Versuch größer; bis auf ganz wenige Ausnahmen ist es mir bisher immer gelungen, nach mehreren Versuchen die komplette Quelldatei einschließlich der beiden Schluß-Tags zu erhalten.
Bearbeiten der Quelldatei
BearbeitenIm Folgenden werden die notwendigen Bearbeitungen der Quelldatei beschrieben, wie sie in verschiedenen Ausgangssituationen erforderlich sein können. Natürlich kann es vorkommen, daß mehrere der hier aufgeführten Punkte zutreffen und die entsprechenden Maßnahmen miteinander kombiniert werden, daß also beispielsweise sowohl das „<title>“-Element verändert, als auch die Quelldatei aufgeteilt und die Versionsgeschichte gekürzt werden muß.
Import aus einem dem Import-Tool nicht zugänglichem Schwester-Projekt oder Artikel mit mehr als 1000 Versionen
BearbeitenDer einfachste Fall liegt vor, wenn es lediglich darum geht, einen Artikel aus einem Schwesterprojekt, das dem Import-Tool nicht zugänglich ist, unter demselben Lemma in die de-wp zu importieren. In diesem Fall kann die XML-Datei so, wie sie ist, importiert werden (siehe unten). Dasselbe gilt, wenn ein Importupload notwendig wurde, weil die Quellartikel mehr als 1000 Versionen hat. Die Beschränkung der Versionsanzahl gilt nur für das automatische Export-Tool, nicht für das Import-Tool.
Import unter anderem Lemma oder Duplikation eines Artikels
BearbeitenWenn lediglich das Lemma geändert werden soll, genügt es, im „<page>“-Element das Element „<title>“ wie gewünscht zu ändern, und die XML-Datei kann importiert werden.
XML-Datei zu groß für Import
BearbeitenWenn die Quelldatei größer als 100 MB ist, muß sie vor dem Import in mehrere kleinere Dateien aufgeteilt werden, die anschleßend nacheinander importiert werden. Aus dem unter #Grundlagen Ausgeführten geht hervor, daß jede dieser Dateien das Wurzelelement, ein „<siteinfo>“- und ein „<page>“-Element enthalten muß, wobei in Letzterem mindestens ein „<revision>“-Element enthalten sein muß. Das praktische Vorgehen gestaltet sich also so, daß man in einem geeigneten Editor (beispielsweise Notepad++ im XML-Modus) eine oder mehrere „Rahmendateien“ anlegt, die das Wurzelelement, das „<siteinfo>“- und das „<page>“-Element mit den Elementen „<title>“, „<ns>“ und „<id>“ jeweils der Original-Datei (bzw. das „<title>“-Element des gewünschten Ziel-Lemmas) enthalten, wobei das „<page>“-Element einer „Rahmendatei“ zunächst ohne „<revision>“-Element angelegt wird. Eine solche „Rahmendatei“ hätte also folgendes Aussehen:
<mediawiki xmlns="http://www.mediawiki.org/xml/export-0.10/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mediawiki.org/xml/export-0.10/ http://www.mediawiki.org/xml/export-0.10.xsd" version="0.10" xml:lang="de">
<siteinfo>
[...]
</siteinfo>
<page>
<title>[...]</title>
<ns>0</ns>
<id>[...]</id>
</page>
</mediawiki>
Zur Erstellung der „Rahmendatei“ kopiert man den Quelltext von der ersten Zeile der Quelldatei bis zur Zeile <id>[...]</id>
in eine neue Datei und kopiert anschließend die beiden letzten Zeilen der Quelldatei, „“ und „ </page>
</mediawiki>
“, darunter. Die so entstandene Datei kann gegebenenfalls wiederum mehrfach kopiert werden.
Nun werden in hinreichender Anzahl vollständige „<revision>“-Elemente (also jeweils vom Tag „<revision>“ bis zum Tag „</revision>“, jeweils einschließlich) aus der Originaldatei ausgeschnitten (nicht: kopiert!) und in die „Rahmendatei“ zwischen den Zeilen <id>[...]</id>
und </page>
eingefügt. Bei einer Quelldatei, die weniger als 200 MB umfaßt, springt man also beispielsweise im Editor bis etwa zur Mitte der Datei, sucht das nächste „<revision>“-Tag, markiert den Quelltext vom Zeilenbeginn des „<revision>“-Tags bis zum Ende der Datei, geht dann mit der Markierung wieder zwei Zeilen zurück (die Zeilen „</page>
“ und „</mediawiki>
“ müssen ja am Ende der Ursprungsdatei enthalten bleiben – das Ende der Markierung sollte sich also jetzt am Ende der drittletzten Zeile der Datei, „</revision>
“ oder am Beginn der vorletzten Zeile, „</mediawiki>
“ befinden), schneidet den markierten Bereich aus und fügt ihn in der „Rahmendatei“ wie beschrieben ein.
Nach dem Speichern der Dateien hat man nun zwei XML-Dateien, die jeweils halb so groß sind wie die Ursprungsdatei. Diese werden nun nacheinander importiert.
Aus praktischen Gründen empfiehlt es sich, bei noch größeren Quelldateien das Prinzip der Halbierung beizubehalten, also – falls notwendig, um unter je 100 MB zu kommen – die beiden so entstandenen Dateien jeweils wiederum zu halbieren.
Überlappende Versionsgeschichten
BearbeitenWird der Import nicht – idealerweise: – vor oder wenigstens unmittelbar nach bsplsw. der Übersetzung durchgeführt, so kann es dazu kommen, daß der Quellartikel bereits weiter verändert wurde, nachdem der Zielartikel erstellt wurde. Technisch wäre zwar auch dann ein Import der Versionsgeschichte des Quellartikels in den Zielartikel möglich, aber die Versionen würden zwischen den beiden Artikelzweigen „hin- und herspringen“, was extrem unübersichtlich ist. Aus urhebererrechtlichen und lizenzrechtlichen Gründen ist ein so vollständiger Import der Versionsgeschichte des Quellartikels nach Abspaltung des Zielartikels keineswegs notwendig. Daher wird in einem solchen Fall die Versionsgeschichte des Quellartikels nur bis zum Zeitpunkt der Abspaltung des Zielartikels importiert. Dazu werden die Versionen, die nicht importiert werden sollen, aus dem XML-Code des Quellartikels gelöscht.
Hierzu vergleicht man zunächst die Versionsgeschichten von Quell- und Zielartikel, stellt fest, welche die letzte Version des Quellartikels ist, die noch importiert werden soll, und notiert dann den timestamp der nächstfolgenden Version. Nach dem Export der Quelldatei sucht man in dieser mit dem Editor nach diesem timestamp, also beispielsweise nach der Zeichenfolge <timestamp>2022-03-03T08:15
(man beachte dabei, daß der timestamp in der XML-Datei in der Regel in UTC festgehalten ist, wohingegen die Versionsgeschichten den Erstellungszeitpunkt einer Version in der Regel in MEZ bzw. MESZ angeben). Hat man den gesuchten timestamp gefunden, so befindet sich aufgrund des immer gleichen Aufbaus der XML-Datei genau zwei Zeilen über dem „<timestamp>“-Element das zugehörige „<revision>“-Tag dieser Artikel-Version. Nun markiert man wiederum vom Zeilenbeginn des „<revision>“-Tags bis zum Ende der Datei, geht dann mit der Markierung wieder zwei Zeilen zurück (die Zeilen „</page>
“ und „</mediawiki>
“ müssen ja am Ende der Ursprungsdatei enthalten bleiben) und löscht die markierten „<revision>“-Elemente.
Bei einem Import der so entstandenen Datei werden nur die Versionen bis zur letzten Version vor der ersten markierten importiert. Es kann sinnvoll sein, weitere, überflüssige Versionen der Quelldatei ebenfalls zu löschen, bsplsw. wenn größere Teile der Versionsgeschichte des Quellartikels wegen Urherberrechtsverletzungen oder aus anderen Gründen bereits versionsgelöscht waren.
Im Ziellemma liegende Weiterleitungen etc.
BearbeitenÜberlappende Versionsgeschichten können sich auch dadurch ergeben, dass das Ziellemma durch Weiterleitungen, Stubs oder Ähnliches belegt ist, die angelegt wurden, bevor ein „richtiger“ Artikel dort entstehen sollte. Da Weiterleitungen etc. in der Regel keine Schöpfungshöhe haben, brauchen sie normalerweise in der Versionsgeschichte auch nicht erhalten zu bleiben. Sie können also, um Überlappungen zu vermeiden, aus der Versionsgeschichte entfernt werden. Dies muß jedoch nicht über eine Manipulation der XML-Datei geschehen, sondern kann über die normalen, jedem Admin zugänglichen Mechanismen der Artikellöschung realisiert werden: In einem solchen Fall wird
- der Zielartikel zunächst (temporär) gelöscht. Hierfür existiert im Dropdown-Menü der Artikel-Löschung die vorbelegte Begründung: „Temporäre Löschung zwecks Import der Versionsgeschichte“,
- anschließend der soeben gelöschte Artikel wieder aufgerufen, was für Admins die Möglichkeit der Wiederherstellung anbietet,
- dann die „Auswahl umgekehrt“, so daß alle Versionen zu Wiederherstellung markiert sind,
- schließlich die Versionen wieder deaktiviert, die keine Schöpfungshöhe haben, und dann
- Wiederherstellen angeklickt.
Dadurch werden die entfernten Versionen in der Versionsgeschichte nicht – zwischen den Versionen des anschließend zu importiernden Quellemmas – als gelöschte Versionen angezeigt, sind aber für Admins weiterhin einsehbar.
Grenzen der Kürzung der Versionsgeschichte
BearbeitenSofern durch Kürzung der Versionsgeschichten nicht dafür gesorgt werden kann, daß einerseits eine überlappungsfreie, andererseits aber auch eine den Lizenzansprüchen genügende Version entsteht – beispielsweise wenn Artikelinhalte in mehreren Etappen oder aus mehreren Artikeln eingefügt werden –, ist der Versionsimport keine geeignete Methode, um den Lizenzansprüchen genüge zu tun. Dann muß ein anderes Verfahren gewählt werden, zum Beispiel das in Hilfe:Artikelinhalte auslagern#Bei fehlgeschlagener Duplizierung sowie zum Übernehmen von Artikelinhalten in einen bestehenden Artikel beschriebene. Zu beachten ist, daß dieses Verfahren nicht – wie der Versionsimport – auch noch nachträglich angewendet werden kann. Einfügungen von relevanter Schöpfungshöhe aus anderen Artikeln ohne Anwendung dieses Verfahrens stellen nicht heilbare Urheberrechts- und Lizenzverletzungen dar, die versionsgelöscht werden müssen.
Import der XML-Datei
BearbeitenAuf der Seite Spezial:Importieren sind zwei unterschiedliche Tools versammelt:
- oben das Tool für den XML-Import und
- unten die in geringem Maße konfigurierbare Version des Interwiki-Import-Tools.
Bedienung des Tools
BearbeitenZur Bedienung des XML-Import-Tools sind folgende Schritte notwendig:
- Die zu importierende Datei wird in der Zeile „Dateiname:“ ausgewählt. Hier öffnet sich beim Klick auf Eine Datei auswählen ein Dateiauswahlfenster des eigenen Betriebssystems, in dem man auf die bekannte Weise zur hochzuladenden Datei navigiert und diese – beispielsweise in Windows – durch Klick auf Öffnen auswählt.
- In der Zeile „Interwiki-Präfix:“ trägt man das Länderkürzel des Projektes ein, aus dem die Quelldatei stammt, also beispielsweise „en“ für einen Import aus der en-WP oder „de“ für eine Duplizierung aus der de-WP. Dieses hier gewählte Kürzel erscheint in der Regel nach dem Import in der Versionsgeschichte mit einem nachgestellten „>“ vor den Benutzenamen der Autoren der importierten Artikelversionen.
- In der Zeile: „Weist Bearbeitungen lokalen Benutzern zu, wo der benannte Benutzer lokal vorhanden ist“, kann man durch Anklicken der Option festlegen, daß bei lokal vorhandenen Benutzern mit diesem Namen der Artikel, in den importiert wird, in der Bearbeitungsliste auftaucht. Dies ist nur dann sinnvoll, wenn der Ursprungsartikel anschließend gelöscht werden soll, da auf diese Weise der Beitrag des Nutzers wenigstens unter dem „neuen Lemma“ in seiner Beitragsliste erhalten bleibt. Gleichzeitig sorgt das Häkchen in diesem Feld dafür, daß dem Benutzernamen in der Versionsgeschichte kein „de>“ vorangestellt wird.
- In der nächsten Zeile wird der Grund für den Import angegeben. Es bietet sich an, hier den Eintrag auf WP:Importwünsche zu verlinken, aufgrund dessen der Import durchgeführt wird. Das dortige Import-Tool stellt nach dem Klick auf Bearbeiten die Versions-ID der Einstellung des Wunsches zur Verfügung (in der dritten Zeile des Importwunsches:
<span style="display:none">[…]diff=
<Versions-ID>}} Antrag])
). Ein möglicher Eintrag in dieser Zeile wäre also beispielsweise: „[[Spezial:Permalink/<Versions-ID>#<Abschnittsüberschrift des Importwunsches>|Importwunsch]]
“. - In den folgenden drei Zeilen kann durch Anklicken eines der Radiobuttons ausgewählt werden, ob
- „zu den Standard-Speicherorten“, also in den im Import-File angegebenen Namensraum, welcher meist der Artikelnamensraum ist,
- „in einen [anderen] Namensraum“ oder
- "als Unterseite der folgenden Seite", also insbesondere in einen Benutzernamensraum, der dann in der Form „
Benutzer:<Benutzername>
“ hier eingetragen werden muß,
- importiert werden soll.
- Ist alles korrekt ausgefüllt, wird der Import durch Klick auf Datei hochladen gestartet.
Mögliche Probleme beim Import und wie man sie vermeidet
Bearbeiten- Vergeht zuviel Zeit zwischen zwei mit dem Tool durchgeführten XML-Importen, gehen die Sitzungsdaten verloren und eine Fehlermeldung erscheint:Import fehlgeschlagen: Die Sitzungsdaten sind verloren gegangen.Das ist völlig unproblematisch. Alle vorgewählten Einstellungen bleiben dabei erhalten, lediglich die Auswahl der zum Upload vorgesehenen Datei geht verloren. Wiederholt man diese Auswahl, kann man den Upload problemlos starten.
Du wurdest eventuell abgemeldet. Bitte stelle sicher, dass du noch angemeldet bist, und versuche es erneut. Falls dies nicht funktioniert, versuche dich abzumelden und anschließend wieder anzumelden und überprüfe, ob dein Browser Cookies von dieser Website akzeptiert.
Es wurde kein Interwiki-Präfix angegeben
Erstaunlicherweise erscheint exakt diese Fehlermelung auch dann, wenn man versehentlich versucht, eine XML-Datei von mehr als 100 MB zu importieren. Wenn man also völlig überraschend auf diese Fehlermeldung stößt, lohnt es sich oft, die Dateigröße der hochzuladenden XML-Datei zu überprüfen (Windows-Nutzer wissen, daß diese Info beim „normalen“ Vorgehen leider nicht angezeigt wird). - Die Operationen auf dem Server sind zeitkritisch und laufen gerne in einen Timeout. Hierzu gibt es zwei Maßnahmen zur Problemvermeidung:
- Der Import in einen nicht vorhandenen Artikel dauert länger als der in einen vorhandenen. Es empfiehlt sich daher insbesondere bei großen XML-Files, den Artikel bereits vor dem Import anzulegen. Man kann dies am einfachsten dadurch tun, dass man den Quellartikel öffnet, auf Bearbeiten klickt, im Bearbeitungsfenster alles markiert, kopiert, dann auf den Rotlink des Zielartikels klickt, diesen anlegt und den kopierten Artikeltext des Quellartikels einfügt. Bei dieser Gelegenheit kann man dann auch gleich die Vorlage:Importartikel in die erste Zeile des Artikels einfügen und die Kategorien deaktivieren. Nach dem Abspeichern führt man dann den XML-Import durch. Dieses Vorgehen beschleunigt übrigens auch den Import mithilfe des halbautomatischen Importtools. Auch dort lohnt es sich bei Quellartikeln mit vielen Versionen, zunächst die Zieldatei mit dem aktuellen Inhalt der Quelldatei anzulegen und erst dann den (dann: Nach-)Import durchzuführen.
- Auch wenn man die Grenze von 100 MB pro XML-Import einhält, kann es passieren, daß der Upload in einen Timeout läuft. Meiner Erfahrung nach hat es wenig Sinn, jetzt nach einem Fehler zu suchen. Man sollte vielmehr die XML-Datei(en) noch einmal halbieren (siehe hier) und die kleineren Dateien der Reihe nach importieren. Das klappt immer.
- Bestimmte Sonderzeichen im Artikellemma führen beim Import zu einem Abbruch nebst unverständlicher Fehlermeldung. Sofern das Sonderzeichen bereits im Quelllemma vorhanden ist, kündigt sich das schon beim Export dadurch an, dass im
<title>
-Element das Lemma vor dem Sonderzeichen abbricht. Das Problem wird dadurch gelöst, dass im<title>
-Element das Sonderzeichen durch seine XML-Entität ersetzt wird: Aus<title>Müller & Co.</title>
wird also beispielsweise<title>Müller & Co.</title>
(dezimale Kodierung) oder<title>Müller & Co.</title>
(hexadezimale Kodierung). Für geläufige Sonderzeichen existieren auch sogenannte benannte Entitäten, beispielsweise „&“ für das „&“ nach der englischen Bezeichnung „Ampersand“ für das kaufmännische Und-Zeichen, so daß sich das Element<title>Müller & Co.</title>
ergäbe. Eine Liste der benannten XML-Entitäten findet sich hier.
Siehe auch
BearbeitenWeitere Anleitungen zu diesem Thema sind: