Interwiki::getURL() accepts an argument, the string to replace $1 with. However it doesn't urlencode it so $interwiki->getURL( 'A&B' ); can return http://somewiki.com/index.php?title=A&B, so the outside caller is required to do the urlencoding instead of the getURL where it should be done (especially since getURL is the one that better understands the context that $1 is in).

Scanning all of trunk and the extensions folder, it doesn't seam like ANY part of core or any extensions make use of Interwiki::getURL with the argument. If any use it they omit the argument and work like Title::getFullURL which itself urlencodes data and does the substitution of $1 on it's own outside of the Interwiki class.

Anyone have an objection to me changing the code so that Interwiki::getURL properly urlencodes it's input and accepts normal text instead of text required to be pre-urlencoded?

Pros: - Saner api - In the future we have the option of deciding to use different urlencoding calls depending on if $1 is located in the path portion of the url or the query portion of the url if it makes sense (like if we ever get [[google:foo bar]] fixed we can use + instead of %20). Cons: - If someone later tries to use Interwiki::getURL inside an extension the argument behavior will be different between versions before 1.19 and 1.19 and after. ie: They'll have to version test for 1.19 and if older add a wfUrlencode call themselves.