Last modified: 2013-06-18 16:16:56 UTC
Special:Import does not seem to care about the name space data in the <sitedata> record in the import. As a result, when names of namespaces differ between the wiki that exported XML data and the wiki that imports it, no mapping occurs of either <title>, <username>, or <text> contents. While this may be desirable at times, mostly one wants namespace prefixes in - <title>namespace:title</title>s ; - <username>namespace:title</username>s ; - [[namespace:link]]s, and [[namespace:pipedlink|xx]] constructs insite <text ...>...</text>; - [[:namespace:link]]s, and [[:namespace:pipedlink|xx]] constructs <text ...>...</text>; - [[namepace:link|with|parameters|etc.]], and [[:namepace:link|with|parameters|etc.]] constructs <text ...>...</ text>; - anything else I might have forgotten mapped from the originating namespaces the those of the target wiki. If that is feasible, I'd suggest a checkbox on the Special:Import page (checked by default) which selects mapping. I do not see applications, but maybe <title>, <username> content and <text> content mapping could each have a checkbox on their own. They're to be coded separately anyways.
*** Bug 9067 has been marked as a duplicate of this bug. ***
Just for the records: I've come across both the necessity to update name space names, and to leave them (effetively shifting some pages to the article name space). We ran a regexp-replace in one case before the import. Which was almost fine, but did not catch the case of a namespace name being passed as a parameter to a template. I've no idea as to how a program might be able to find occurrences like these. Another such case might be plain name space names in plain text. Both should imho be considered coding errors; editors should use {{NS:...}} instead of plain name space names, appropriately. Another point worth considering might be that some NS need mapping while other must not be mapped. (Thanks to my brother for pointing out) So, if such mapping should be integrated into the import (or export) process anyways, it might be a good idea to allow the entire mapping be configurable on a per-NS-basis. This would require a 2-step process on import, with the drawback of having to keep the uploaded file until after a user has configured his/her mapping - which may never happen. It would be a 1-step process on export, with the drawback of errors not showing immeditely - they cannot be corrected except by a complete re-export. Of course, once the program logic is there, it can easily be tied to both import, and export, for added flexibility.
Mass compoment change: <some> -> Export/Import
*** Bug 15387 has been marked as a duplicate of this bug. ***
Closing in favour of the more general bug 30723. Problems with usernames and attribution in history are tracked at bug 7240. Transclusion calls by different namespace names must be fixed by editing the XML. *** This bug has been marked as a duplicate of bug 30723 ***
