- On the source wiki, the commons: prefix is an interwiki prefix that points to Commons.
- On Commons, there is no commons: interwiki prefix, because – well – we are already on Commons. But there is a Commons: namespace. That's the local project namespace that is called Wikipedia: and such in other projects.
- Therefor, the prefix commons: is detected to be a namespace, and de-localized to Project:.
- Additionally, the :et: interwiki prefix is added to point back to the source wiki.
Issues with that, and possible ways forward:
- A trivial workaround might be to make the project namespace a special case, and always exclude it from the namespace de-localization.
- Another (fragile!) workaround might be to assume the target wikis project namespace is identical to the interwiki prefix that represents the target wiki on the source wiki. In the example, the commons: interwiki prefix is identical to the namespace Commons: on Commons. If this is the case, we just remove it.
- Another fix might be to check if a link contains more than one colon, and do not do any namespace de-localization on the first part then. That would certainly be wrong, because in a link like [[A:B:C]] only the B can be a namespace, but the A can't. Note that this fix does not cover links to the main namespace. These would still break.
- We could teach the wikitext cleaner about interwiki prefixes as they are on the source wiki. Fetching this information is technically possible. An open question is what to do with this information. Should [[commons:x]] become [[:et:commons:x]] or [[x]]? And is the use-case of "links pointing to the main namespace of the target wiki" even relevant?
- Import a test file with specially prepared links.
- In the import preview, the enwiki link should point to the "Wikipedia" namespace, and the commons link to the "Commons" namespace.
- The user link should still read "Benutzer".
- Now, import from beta dewiki
- This file should still read "Commons:", however the user link will be translated to the "User" namespace.