The ksort() here was causing the order to be enforced as
alphabetical instead of preserving the original order.
The order usually doesn't matter, except with regards to handling
of duplicates. Due to Parsoid normalising external links to interwiki
links, it has to do a reverse lookup. In doing so it has to decide
which one to prefer. It currently picks the first match from the
API request for meta=siteinfo&siprop=interwikimap, which didn't
match the defined order in the actual Interwiki map due to ksort()
being called in getAllPrefixes().
Sort in this function was originally introduced in 2010 with
commit 844e7c83e4 (2011; r92528; T21838), which is otherwise unrelated
and left no rationale.
The existing unit tests needed to be adjusted slightly as they
assumed alphabetical order. While it appeared they were also defined
in alphabetical order, this was merely the order of the variable
creation. The effective order is preserved within locals and globals,
but overall globals come before locals.
Also removed the duplicate test for Hash and CDB in InterwikiTest
that belongs in ClassicInterwikiLookupTest instead.
Bug: T145337
Change-Id: I7348748801cbdf16c6ceea5b0654fc174b79707e
This keeps the existing app logic for looking up interwiki information
intact in ClassicInterwikiLookup. The idea is to seamlessly switch to a new
implementation when it becomes available, while also allowing us to
switch back in case of problems.
Change-Id: I7d7424345d0ce3ce90ba284006ee9615e3d99baa
This test class verifies that Interwiki currectly handles information
from the database, CDB files, and plain arrays. This is intended to
allow confident refactoring when implementing T113034.
Bug: T113034
Change-Id: I2b68d11e3e946d81fa5f5f65a28fc399e7936c0f
