Merge branch 'master' of git://github.com/joeyh/ikiwiki

master
Amitai Schlair 2009-09-08 13:08:49 -04:00
commit 1332327f5e
5 changed files with 54 additions and 5 deletions

View File

@ -5,8 +5,8 @@
This plugin allows ikiwiki to use [[!wikipedia desc="CVS" Concurrent Versions System]] as an [[rcs]].
### Usage
7. Install [cvsps](http://www.cobite.com/cvsps/), [[!cpan IPC::Cmd]],
[[!cpan String::ShellQuote]], [[!cpan File::ReadBackwards]], and
7. Install [cvsps](http://www.cobite.com/cvsps/), [[!cpan
File::ReadBackwards]], and
[cvsweb](http://www.freebsd.org/projects/cvsweb.html) or the like.
7. Adjust CVS-related parameters in your setup file.

View File

@ -122,3 +122,6 @@ to run the command, with stderr temporarily sent to /dev/null:
`cvs_runcvs` should not take an array reference. It's
usual for this type of function to take a list of parameters
to pass to the command.
> Thanks for reading carefully. I've tested your suggestions and
> applied them on my branch. --[[schmonz]]

View File

@ -64,3 +64,10 @@ Do you like it? Can you implement the same in Ikiwiki? :) --[[Paweł|ptecza]]
>> was written rather for simple usage. However cell alignment is very
>> helpful feature, so I think the plugin should be able to do it.
>> --[[Paweł|ptecza]]
-----
If you see `[[!table\ Error: ]]` you probably need to `sudo apt-get install libtext-csv-perl`.
> Perhaps more helpfully, ikiwiki 3.1415926 fixes display of such errors to
> actualy include the error message. --[[Joey]]

View File

@ -14,6 +14,8 @@ and there is a po/ikiwiki.pot in the source that can be translated.
----
## template i18n
From [[Recai]]:
> Here is my initial work on ikiwiki l10n infrastructure (I'm sending it
> before finalizing, there may be errors).
@ -64,9 +66,19 @@ Birisi[1], ki muhtemelen bu sizsiniz, <TMPL_VAR WIKINAME>[2] üzerindeki
bulundu. Parola: <TMPL_VAR USER_PASSWORD> -- ikiwiki [1] Parolayı isteyen
kullanıcının ait IP adresi: <TMPL_VAR REMOTE_ADDR>[2] <TMPL_VAR WIKIURL>
> Looks like, tmpl_process3 cannot preserve line breaks in template files.
> For example, it processed the following template:
This could be easily worked around in tmpl_process3, but I wouldn't like to
maintain a separate utility.
----
Another way to approach this would be to write a small program that outputs
the current set of templates. Now i18n of that program is trivial,
and it can be run once per language to generate localized templates.
Then it's just a matter of installing the templates somewhere, and having
them be used when a different language is enabled.
It would make sense to make the existing `locale` setting control which
templates are used. But the [[plugins/po]] plugin would probably want to do
something more, and use the actual language the page is written in.
--[[Joey]]

View File

@ -0,0 +1,27 @@
[[!tag wishlist]]
## Idea
After searching from the most local to the root for a wikilinkable page, descend into the tree of pages looking for a matching page.
For example, if I link to \[\[Pastrami\]\] from /users/eric, the current behavior is to look for
* /users/eric/pastrami
* /users/pastrami
* /users/eric/pastrami
I'd like it to find /sandwiches/pastrami.
## Issues
I know this is a tougher problem, especially to scale efficiently. There is also not a clear ordering unless it is the recursive dictionary ordering (ie the order of a breadth-first search with natural ordering). It would probably require some sort of static lookup table keyed by pagename and yielding a path. This could be generated initially by a breadth-first search and then updated incrementally when pages are added/removed/renamed. In some ways a global might not be ideal, since one might argue that the link above should match /users/eric/sandwiches/pastrami before /sandwiches/pastrami. I guess you could put all matching paths in the lookup table and then evaluate the ordering at parse-time.
## Motivation
Since I often access my documents using a text editor, I find it useful to keep them ordered in a heirarchy, about 3 levels deep with a branching factor of perhaps 10. When linking though, I'd like the wiki to find the document for me, since I am lazy.
Also, many of my wiki pages comprise the canonical local representation of some unique entity, for example I might have /software/ikiwiki. The nesting, however, is only to aid navigation, and shouldn't be considered as part of resource's name.
## Alternatives
If an alias could be specified in the page body (for example, /ikiwiki for /software/ikiwiki) which would then stand in for a regular page when searching, then the navigational convenience of folders could be preserved while selectively flattening the search namespace.