Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

master
Joey Hess 2010-06-27 13:50:02 -04:00
commit be60d261e6
12 changed files with 95 additions and 4 deletions

View File

@ -0,0 +1,17 @@
The po plugin's protection against processing loops (i.e. the
alreadyfiltered stuff) is playing against us: the template plugin
triggers a filter hooks run with the very same ($page, $destpage)
arguments pair that is used to identify an already filtered page.
Processing an included template can then mark the whole translation
page as already filtered, which prevented `po_to_markup` to be called on
the PO content.
Symptoms: the unprocessed gettext file goes unfiltered to the
generated HTML.
This has been fixed in my po branch.
-- [[intrigeri]]
[[!tag patch]]

View File

@ -84,3 +84,8 @@ Is it possible to refer to a page, say \[[foobar]], such that the link text is t
> Not yet. :-) Any suggestion for a syntax for it? Maybe something like \[[|foobar]] ? --[[Joey]]
I like your suggestion because it's short and conscise. However, it would be nice to be able to refer to more or less arbitrary meta tags in links, not just "title". To do that, the link needs two parameters: the page name and the tag name, i.e. \[[pagename!metatag]]. Any sufficiently weird separater can be used instead of '!', of course. I like \[[pagename->metatag]], too, because it reminds me of accessing a data member of a structure (which is what referencing a meta tag is, really). --Peter
> I dislike \[[pagename->metatag]] because other wikis use that as their normal link/label syntax.
> I'm not sure that it is a good idea to refer to arbitrary meta tags in links in the first place - what other meta tags would you really be interested in? Description? Author? It makes sense to me to refer to the title, because that is a "label" for a page.
> As for syntax, I do like the \[[|foobar]] idea, or perhaps something like what <a href="http://www.pmwiki.org">PmWiki</a> does - they have their links the other way around, so they go \[[page|label]] and for link-text-as-title, they have \[[page|+]]. So for IkiWiki, that would be \[[+|page]] I guess.
> --[[KathrynAndersen]]

View File

@ -147,6 +147,7 @@ Personal sites and blogs
* [Ertug Karamatli](http://pages.karamatli.com)
* [Jonatan Walck](http://jonatan.walck.i2p/) a weblog + wiki over [I2P](http://i2p2.de/). Also [mirrored](http://jonatan.walck.se/) to the Internet a few times per day.
* [Daniel Wayne Armstrong](http://circuidipity.com/)
* [Mukund](https://www.mukund.org/)
Please feel free to add your own ikiwiki site!

View File

@ -324,3 +324,5 @@ smcv's discuission of field author vs meta author above. --[[Joey]]
>>> the side-effects, but use `field` as an interface to get the values of those special fields.
>>> --[[KathrynAndersen]]
I was just looking at HTML5 and wondered if the field plugin should generate the new Microdata tags (as well as the internal structures)? <http://slides.html5rocks.com/#slide19> -- [[Will]]

View File

@ -263,6 +263,9 @@ order, as `po_slave_languages` is a hash. It would need to be converted
to an array to support this. (If twere done, twere best done quickly.)
--[[Joey]]
> Done in my po branch, preserving backward compatibility. Please
> review :) --[[intrigeri]]
Pagespecs
---------
@ -290,6 +293,9 @@ Also, this may only happen if the page being linked to is coming from an
underlay, and the underlays lack translation to a given language.
--[[Joey]]
> Any simple testcase to reproduce it, please? I've never seen this
> happen yet. --[[intrigeri]]
Double commits of po files
--------------------------
@ -304,11 +310,18 @@ and then committed again. The second commit makes this change:
Same thing happens when a change to an existing page triggers a po file
update. --[[Joey]]
> * The s/utf-8/UTF-8 part is fixed in my po branch.
> * The ENCODING\n part is due to an inconsistency in po4a, which
> I've just send a patch for. --[[intrigeri]]
Ugly messages with empty files
------------------------------
If there are empty .mdwn files, the po plugin displays some ugly messages.
> This is due to a bug in po4a (not checking definedness of a
> variable). One-liner patch sent. --[[intrigeri]]
Translation of directives
-------------------------

View File

@ -20,8 +20,9 @@ Consider creating `$HOME/.cvsrc` if you don't have one already; the plugin doesn
* creates a repository,
* imports `$SRCDIR` into top-level module `ikiwiki` (vendor tag IKIWIKI, release tag PRE_CVS),
* configures the post-commit hook in `CVSROOT/loginfo`.
* CVS multi-directory commits happen separately; the post-commit hook sees only the first directory's changes in time for [[recentchanges|plugins/recentchanges]]. The next run of `ikiwiki --setup` will correctly re-render such a recentchanges entry. It should be possible to solve this problem with NetBSD's `commit_prep` and `log_accum` scripts (see below).
### To do
* Instead of resource-intensively scraping changesets with `cvsps`, have `ikiwiki-makerepo` set up NetBSD-like `log_accum` and `commit_prep` scripts that coalesce and keep records of commits. `cvsps` can be used as a fallback for repositories without such records.
* Have `ikiwiki-makerepo` set up NetBSD-like `log_accum` and `commit_prep` scripts that coalesce commits into changesets. Reasons:
7. Obviates the need to scrape the repo's complete history to determine the last N changesets. (Repositories without such records can fall back on the `cvsps` and `File::ReadBackwards` code.)
7. Arranges for ikiwiki to be run once per changeset, rather than CVS's once per committed file (!), which is a waste at best and bug-inducing at worst. (Currently, on multi-directory commits, only the first directory's changes get mentioned in [[recentchanges|plugins/recentchanges]].)
* Perhaps prevent web edits from attempting to create `.../CVS/foo.mdwn` (and `.../cvs/foo.mdwn` on case-insensitive filesystems); thanks to the CVS metadata directory, the attempt will fail anyway (and much more confusingly) if we don't.

View File

@ -1,5 +1,11 @@
This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version ]]).
<<<<<<< HEAD
Test conflict.
=======
Testing 123.
>>>>>>> 8cc8bb52f7913e429be7e14203177ef374645718
# Header
## Subheader2

View File

@ -177,7 +177,7 @@ about using the git repositories.
Once your wiki is checked in to the revision control system, you should
configure ikiwiki to use revision control. Edit your ikiwiki.setup, set
`rcs` to the the revision control system you chose to use. Be careful,
`rcs` to the revision control system you chose to use. Be careful,
you may need to use the 'fullname'. For example, 'hg' doesn't work, you
should use mercurial. Be sure to set `svnrepo` to the directory for your
repository, if using subversion. Uncomment the configuration for the wrapper

View File

@ -0,0 +1,7 @@
The HTML page type should be fully supported by the PO plugin: po4a's
HTML support is able to extract translatable strings and to disregard
the rest.
This is implemented in my po branch, please review. --[[intrigeri]]
[[!tag patch]]

View File

@ -6,3 +6,5 @@ isn't. --[[intrigeri]]
Fixed in my po branch. --[[intrigeri]]
[[!tag patch]]
> bump?

View File

@ -34,6 +34,8 @@ those contents instead.
>>>>> if I want to try to get a 3 column CSS going, so perhaps leave the
>>>>> left sidebar out of that.
-------------------
<pre>
--- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm 2010-02-11 22:53:17.000000000 -0500
+++ plugins/IkiWiki/Plugin/sidebar.pm 2010-02-27 09:54:12.524412391 -0500
@ -85,4 +87,39 @@ those contents instead.
}
</pre>
----------------------------------------
## Further thoughts about this
(since the indentation level was getting rather high.)
What about using pagespecs in the config to map pages and sidebar pages together? Something like this:
<pre>
sidebar_pagespec => {
"foo/*" => 'sidebars/foo_sidebar',
"bar/* and !bar/*/*' => 'bar/bar_top_sidebar',
"* and !foo/* and !bar/*" => 'sidebars/general_sidebar',
},
</pre>
One could do something similar for *pageheader*, *pagefooter* and *rightbar* if desired.
Another thing which I find compelling - but probably because I am using [[plugins/contrib/field]] - is to be able to treat the included page as if it were *part* of the page it was included into, rather than as an included page. I mean things like \[[!if ...]] would test against the page name of the page it's included into rather than the name of the sidebar/header/footer page. It's even more powerful if one combines this with field/getfield/ftemplate/report, since one could make "generic" headers and footers that could apply to a whole set of pages.
Header example:
<pre>
#{{$title}}
\[[!ftemplate id="nice_data_table"]]
</pre>
Footer example:
<pre>
------------
\[[!report template="footer_trail" trail="trailpage" here_only=1]]
</pre>
(Yes, I am already doing something like this on my own site. It's like the PmWiki concept of GroupHeader/GroupFooter)
-- [[KathrynAndersen]]
[[!tag wishlist]]

View File

@ -2,4 +2,4 @@
[[!map pages="!*/Discussion and ((link(users/schmonz) and plugins/*) or rcs/cvs)"]]
In progress: a plugin for [WIND authentication](http://www.columbia.edu/acis/rad/authmethods/wind/).
I've also written a plugin for [WIND authentication](http://www.columbia.edu/acis/rad/authmethods/wind/), which may or may not be of general utility.