]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/bugs/pagetitle_function_does_not_respect_meta_titles.mdwn
Greek hello
[git.ikiwiki.info.git] / doc / bugs / pagetitle_function_does_not_respect_meta_titles.mdwn
index 4a83f9ec8ab8d1f77dda156842c436281e1ea85c..15d28f9893865855c5817ca4ab860acffdf3c341 100644 (file)
@@ -1,3 +1,5 @@
+[[!tag patch plugins/inline patch/core]]
+
 The `IkiWiki::pagetitle` function does not respect title changes via `meta.title`. It really should, so that links rendered with `htmllink` get the proper title in the link text.
 
 --[[madduck]]
 The `IkiWiki::pagetitle` function does not respect title changes via `meta.title`. It really should, so that links rendered with `htmllink` get the proper title in the link text.
 
 --[[madduck]]
@@ -5,7 +7,7 @@ The `IkiWiki::pagetitle` function does not respect title changes via `meta.title
 ----
 
 It is possible to set a Page-Title in the meta-plugin, but that one isn't
 ----
 
 It is possible to set a Page-Title in the meta-plugin, but that one isn't
-reused in parentlinks. This [[patch]] may fix it.
+reused in parentlinks. This patch may fix it.
 
 <ul>
 <li> I give pagetitle the full path to a page.
 
 <ul>
 <li> I give pagetitle the full path to a page.
@@ -132,7 +134,7 @@ diff -c /usr/share/perl5/IkiWiki/Plugin/meta.pm.distrib /usr/share/perl5/IkiWiki
 >
 >> It was actually more complicated than expected. A working prototype is
 >> now in my `meta` branch, see my userpage for the up-to-date url.
 >
 >> It was actually more complicated than expected. A working prototype is
 >> now in my `meta` branch, see my userpage for the up-to-date url.
->> Thus tagging [[patch]]. --[[intrigeri]]
+>> Thus tagging patch. --[[intrigeri]]
 >>
 >>> Joey, please consider merging my `meta` branch. --[[intrigeri]]
 
 >>
 >>> Joey, please consider merging my `meta` branch. --[[intrigeri]]
 
@@ -142,7 +144,7 @@ So, looking at your meta branch: --[[Joey]]
   has no title, then A will display the link as "B". Now page B is modified
   and a title is added. Nothing updates "A".
   The added overhead of rebuilding every page that links to B when B is
   has no title, then A will display the link as "B". Now page B is modified
   and a title is added. Nothing updates "A".
   The added overhead of rebuilding every page that links to B when B is
-  changed (as the `postscan` hook of the po plugin does) is IMHO a killer.
+  changed (as the `indexhtml` hook of the po plugin does) is IMHO a killer.
   That could be hundreds or thousands of pages, making interactive editing
   way slow. This is probably the main reason I had not attempted this whole
   thing myself. IMHO this calls for some kind of intellegent dependency
   That could be hundreds or thousands of pages, making interactive editing
   way slow. This is probably the main reason I had not attempted this whole
   thing myself. IMHO this calls for some kind of intellegent dependency
@@ -231,3 +233,57 @@ So, looking at your meta branch: --[[Joey]]
 >> handling, since po contains a workaround for that, and it's probably
 >> acceptable to use potentially slow methods to handle this case.)
 >> --[[Joey]] 
 >> handling, since po contains a workaround for that, and it's probably
 >> acceptable to use potentially slow methods to handle this case.)
 >> --[[Joey]] 
+
+>>> 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]]