From: Joey Hess Date: Sun, 26 Dec 2010 17:53:31 +0000 (-0400) Subject: Merge remote branch 'smcv/ready/urlto' X-Git-Tag: 3.20101231~28 X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/commitdiff_plain/9982862925627d4714ed8b61d8b591950ed5aaa5?hp=be6ca4c4e99c40f4c4763147c798a6f144dadc0c Merge remote branch 'smcv/ready/urlto' --- diff --git a/doc/bugs/urlto_API_change_breaks_wikis_with_po_plugin.mdwn b/doc/bugs/urlto_API_change_breaks_wikis_with_po_plugin.mdwn index ba203c32b..fc0672d0a 100644 --- a/doc/bugs/urlto_API_change_breaks_wikis_with_po_plugin.mdwn +++ b/doc/bugs/urlto_API_change_breaks_wikis_with_po_plugin.mdwn @@ -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 index 000000000..73ffe3e16 --- /dev/null +++ b/doc/bugs/urlto__40____34____34____44___...__44___1__41___not_absolute.mdwn @@ -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]] diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index 3cab7588e..adc20af72 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -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 diff --git a/doc/todo/transient_pages.mdwn b/doc/todo/transient_pages.mdwn index 47af92686..7e8c86592 100644 --- a/doc/todo/transient_pages.mdwn +++ b/doc/todo/transient_pages.mdwn @@ -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