+
+>>> I'm glad to implement whatever decision we'll make, but I don't
+>>> clearly understand what this discussion's conclusion is. It seems
+>>> like we agree at least on one point: meta page titles shall not be
+>>> displayed all over the place by default; I have therefore disabled
+>>> `meta_overrides_page_title` by default in my `meta` branch.
+>>>
+>>> My next question is then: do we only want to satisfy the `po`
+>>> plugin needs? Or do we want to allow people who want this, such as
+>>> [[madduck]], to turn on a config switch so that meta page titles
+>>> are displayed as wikilinks titles? In the latter case, what level
+>>> of configurability do we want? I can think of a quite inelegant
+>>> way to implement full configurability, and provide a configuration
+>>> switch for every place where links are displayed, such as
+>>> wikilinks, parentlinks, etc., but I don't think the added bonus is
+>>> worth the complexity of it.
+>>>
+>>> I think we can roughly split the needs into three categories:
+>>>
+>>> 1. never display any modified page title in links; this is the
+>>> current behaviour, and we should keep it as the default one
+>>> 2. display modified page titles only at well chosen places; that
+>>> could be "manual" wikilinks, I mean those generated by the
+>>> `link`, `camelcase` & al. plugins, the recentchanges page, and
+>>> maybe a few other places; keep the usual pagename-based title
+>>> for every other link, such as the parentlinks ones.
+>>> The inter-page dependency problem remains, though. As a first
+>>> step, I'm in favour of the "slow, but correct" implementation,
+>>> with a big warning stating that enabling this option can make
+>>> a wiki really sluggish; if someone really wants this to work
+>>> fast, he/she'll implement a clever dependency handler :)
+>>> 3. display modified page titles all over the place; IMHO, we
+>>> should implement only the bits needed so that the `po` plugin
+>>> can set this up, rather than provide this as
+>>> a user-configurable option.
+>>>
+>>> So my question is: do we want to implement the #2 case, or not?
+>>> I propose myself to only implement #1 and #3 to start with, but do
+>>> it in a way that leaves room for #2.
+>>>
+>>> --[[intrigeri]]
+>>>
+>>>> I agree, we should concentrate on getting just enough functionality
+>>>> for the po plugin, because I want to merge the po plugin soon.
+>>>> If #2 gets tackled later, we will certianly have all kinds of fun.
+>>>> no matter what is done for the po plugin. --[[Joey]]
+
+>>>>> For the record: I've gotten used to the lack of this feature,
+>>>>> and it now seems much less important to me than it was when
+>>>>> initially developing the po plugin. So, I'm hereby officially
+>>>>> removing this from my plate. If anyone else wants to start from
+>>>>> scratch, or from my initial work, I'm happy to review the
+>>>>> po-related part of things -- just drop me an email in this
+>>>>> case. --[[intrigeri]]