]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/commitdiff
Merge remote branch 'smcv/ready/urlto'
authorJoey Hess <joey@kitenet.net>
Sun, 26 Dec 2010 17:53:31 +0000 (13:53 -0400)
committerJoey Hess <joey@kitenet.net>
Sun, 26 Dec 2010 17:53:31 +0000 (13:53 -0400)
doc/bugs/urlto_API_change_breaks_wikis_with_po_plugin.mdwn
doc/bugs/urlto__40____34____34____44___...__44___1__41___not_absolute.mdwn [new file with mode: 0644]
doc/plugins/write.mdwn
doc/todo/transient_pages.mdwn

index ba203c32b738752eefbd9b37f82a699bf671181f..fc0672d0a1b31c18b8e54ba15dcfbc90e5f5fba1 100644 (file)
@@ -29,3 +29,66 @@ investigated this yet.
 > something. --[[smcv]]
 
 >> I'm leaving this bug report open until this can be checked. --[[Joey]] 
+
+>>> My `ready/urlto` branch improves the test coverage. The bugfix from
+>>> that branch fixes most of `po` too, but leaves behind some perhaps
+>>> less-than-ideal behaviour: links where the current language is unknown,
+>>> with `po_link_to = current`, always go to the master language,
+>>> whereas perhaps it'd be better to go to the negotiated language in
+>>> this case? --[[smcv]]
+
+>>>> Thanks for taking care, thanks for these improvements!
+>>>>
+>>>> OTOH I consider any of these behaviours (either the brand new one
+>>>> = link to master language, or the alternative one = link to
+>>>> negotiated) as a regression. Any of these is contrary to what
+>>>> `po_link_to = current` is supposed to do according to the
+>>>> documentation.
+>>>>
+>>>> Let's be less technical, let me display my practical usecase
+>>>> (making this possible was one of the main reasons I initially
+>>>> implemented `po_link_to = current`).
+>>>>
+>>>> Summary: the current state of things is an annoying regression
+>>>> and it needs to be fixed.
+>>>>
+>>>> Context: I participate in building a Live system based on Debian
+>>>> Live; the project's multilingual website
+>>>> ([T(A)ILS](https://amnesia.boum.org/) is built using ikiwiki. A
+>>>> static / offline copy is shipped on ISO images; this is the way
+>>>> end-user documentation lands on the CDs. Note that no webserver
+>>>> runs on the Live system to serve this wiki, so `po_link_to =
+>>>> current` is compulsory. A user can choose her preferred language
+>>>> at boot time. Depending on her decision, The desktop shortcut
+>>>> that points to the embedded documentation (i.e. static wiki)
+>>>> links to a different entry point depending on the chosen
+>>>> language.
+>>>>
+>>>> The previous (documented) behaviour was deadly simple:  if I am
+>>>> presented a page in English (master language) it means it does
+>>>> not exist in my preferred language; the computer always displays
+>>>> me the best available version according to my needs. The new
+>>>> behaviour brings a troubling seemingly random factor into the
+>>>> user navigation experience and IMHO is a mess from a web
+>>>> ergonomics point of view (no content negotiation available,
+>>>> remember): I sometimes am shown an English page although it is
+>>>> fully translated in my language one click away, and on the
+>>>> contrary I sometimes I am shown the optimal page. This, is, well,
+>>>> interesting. This practically forces the non-English speaking
+>>>> website visitor to check the otherlanguages list on every single
+>>>> page to make sure *herself* there is nothing better available,
+>>>> and sometimes click on her preferred language link to get a page
+>>>> she actually can read.
+>>>>
+>>>> I unfortunately might not be able to dedicate the needed time to
+>>>> help fix this in a timely manner, so I don't want to urge anyone.
+>>>> Take care!  --[[intrigeri]]
+
+>>>>> I can see why this is bad, but to the best of my knowledge it's
+>>>>> not a regression: each of the calls to 1-argument `urlto` was
+>>>>> previously a call to 3-argument `urlto`, which always produces
+>>>>> a fully absolute URL, so in either case there isn't enough
+>>>>> context to know the current language. Links that were previously
+>>>>> 2-argument `urlto` still have a defined second argument;
+>>>>> I've just edited `plugins/write` to clarify why the second
+>>>>> argument should be provided whenever possible. --[[smcv]]
diff --git a/doc/bugs/urlto__40____34____34____44___...__44___1__41___not_absolute.mdwn b/doc/bugs/urlto__40____34____34____44___...__44___1__41___not_absolute.mdwn
new file mode 100644 (file)
index 0000000..73ffe3e
--- /dev/null
@@ -0,0 +1,7 @@
+[[!template id=gitbranch branch=smcv/ready/urlto author="[[Simon_McVittie|smcv]]"]]
+[[!tag patch]]
+
+urlto() has a special-case for a zero-length first argument, but it
+produces a relative path even if the third argument is given and true.
+
+My `ready/urlto` branch simplifies this special case so it works. --[[smcv]]
index 3cab7588ec99c7a83fa6755fe3870fc93d6fb4d3..adc20af72331ec83e208d73d3772308a37263a3b 100644 (file)
@@ -988,6 +988,9 @@ Construct a relative url to the first parameter from the page named by the
 second. The first parameter can be either a page name, or some other
 destination file, as registered by `will_render`.
 
+Provide a second parameter whenever possible, since this leads to better
+behaviour for the [[plugins/po]] plugin and `file:///` URLs.
+
 If the second parameter is not specified (or `undef`), the URL will be
 valid from any page on the wiki, or from the CGI; if possible it'll
 be a path starting with `/`, but an absolute URL will be used if
index 47af9268685c5f77256bff8b3d4898ddfd820c9c..7e8c86592a4286655dade61e48cb20b028de2298 100644 (file)
@@ -27,7 +27,9 @@ content for the edit box; after that, it'd become a static page. --[[smcv]]
 I think this branch is now enough to be useful. It adds the following:
 
 If the `transient` plugin is loaded, `$srcdir/.ikiwiki/transient` is added
-as an underlay.
+as an underlay. I'm not sure whether this should be a plugin or core, so
+I erred on the side of more plugins; I think it's "on the edge of the core",
+like goto.
 
 Pages with the default extension in the transient underlay are automatically
 deleted if a page of the same name is created in the srcdir (or an underlay
@@ -35,26 +37,30 @@ closer to the srcdir in stacking order).
 
 `tag` enables `transient`, and if `tag_autocreate_commit` is set to 0
 (default 1), autocreated tags are written to the transient underlay.
+There is a regression test.
 
 `autoindex` uses autofiles. It also enables `transient`, and if
 `autoindex_commit` is set to 0 (default 1), autoindexes are written to
-the transient underlay.
+the transient underlay. There is a regression test.
 
 autoindex ignores pages in the transient underlay when deciding whether
 to generate an index.
 
-Not done yet:
+New recent changes go in the transient underlay; I tested this manually.
 
-`remove` can't remove transient pages: this turns out to be harder than
-I'd hoped, because I don't want to introduce a vulnerability in the
-non-regular-file detection...
+Not done yet (in that branch, at least):
 
-Transient tags that don't match any pages aren't deleted: I'm not sure
-that that's a good idea anyway, though. Similarly, transient autoindexes
-of directories that become empty aren't deleted.
+* `remove` can't remove transient pages: this turns out to be harder than
+  I'd hoped, because I don't want to introduce a vulnerability in the
+  non-regular-file detection, so I'd rather defer that.
 
-Recent changes and aggregated files could conceivably go in the transient
-underlay too.
+* Transient tags that don't match any pages aren't deleted: I'm not sure
+  that that's a good idea anyway, though. Similarly, transient autoindexes
+  of directories that become empty aren't deleted.
+
+* In my `untested/transient` branch, new aggregated files go in the
+  transient underlay too (they'll naturally migrate over time). I haven't
+  tested this yet, it's just a proof-of-concept.
 
 > I can confirm that the behavior of autoindex, at least, is excellent.
 > Haven't tried tag. Joey, can you merge transient and autoindex? --JoeRayhawk