Issue: Special characters like ä are not imported correctly

There are really a lot of such cases.

1) In your includes/config.php file, is this line NOT commented?
And did you leave the following blank in vault/core/controller/import/config/vw.php:
OR
2) Alternatively, is the line in includes/config.php file commented, or 'latin1'?
And did you set the vault/core/controller/import/config/vw.php line like so:

If either of these combinations were in effect, that explains why this happened.

includes/config.php
has
// $config['Mysqli']['charset'] = 'utf8';

vault/core/controller/import/config/vw.php
has
// charset is not defined in LocalSettings.php, but is not guaranteed as 'utf8' in MW
'charset' => '',

Does this bug only affect the names or the body text as well?

body text as well.

Also in comment signatures.

This is something I would like to look into, but it would require FTP access so that I can compare all the different encodings (input to the database, storage in the database, the connection used by vBulletin, the connection used by the importer, and what the importer decides when it tries to detect each of these). It looks like there was a problem somewhere, but unfortunately I will have to go line-by-line to find it, on an import where the problem occurs. Believe me I have done VW3 imports with Asian characters that came out just fine.

There are a few other issues I've noticed, such as some attachments have invalid description URLs that do not rebuild successfully. Also there was a problem where absolutely no default setting values were applied at installation (and this is the first time I've ever seen that).

By the URLs you've sent me, I am under the impression that this is was test import. Would it be safe to clear the VW4 wiki data so that I can see what happens as each item gets imported? I understand you must whitelist my IP through a firewall. I'm PMing that info to you now.

Yes, this is a test import. I expected that importing this large data set over so many VW version would result in hiccups.
I will send you the details as soon as another developer is finished with the dev site.

Double encoding (e.g. & becomes &amp occurred only for area titles, social group titles, and redirect titles for redirects that are created automatically to deal with high-level conflicts - like two index pages or two areas with the same name. This is now fixed.

Apparently the other problem wasn't an issue with the importer at all, but rather that vBulletin 3 behaves a little differently from vBulletin 4: it sends the content-type and charset headers before the styles are loaded. Thus, VaultWiki saying that the charset was UTF-8 occurred too late, because a charset=ISO-8859-1 header was already sent. Even though characters were properly converted and the HTML output was fully UTF-8, vBulletin already sent a header to the browser telling it to expect ISO-8859-1 content. This was resolved by moving VaultWiki's code that changes the character set to an earlier location in vBulletin 3.

Unfortunately this is not fixed.

There were 3 or 4 various bugs here. Which aspect are you referring to?

Please see the wiki: H?ufig gestellte Fragen
This should have been: Häufig gestellte Fragen

I assume that there are similar issues with special characters.

There was a typo in a new and important regular expression (an opening [ was missing). I will reinstall and run the import again.

Great. Let me know how it goes.