Similarly to po: apache config serves index.rss for index, the po apache config has another bug.

The use of "DirectoryIndex index", when combined with multiviews, is intended to serve up a localized version of the index.??.html file.

But, if the site's toplevel index page has a discussion page, that is "/index/discussion/index.html". Or, if the img plugin is used to scale an image on the index page, that will be "/index/foo.jpg". In either case, the "index" directory exists, and so apache happily displays that directory, rather than the site's index page!

--Joey

Ack, we do have a problem. Seems like ikiwiki's use of index/ as the directory for homepage's sub-pages and attachments makes it conflict deeply with Apache's MultiViews: as the MultiViews documentation says, index.* are considered as possible matches only if the index/ directory does not exist. Neither type maps nor mod_mime config parameters seem to allow overriding this behavior. Worse even, I guess any page called index would have the same issues, not only the wiki homepage.

I can think of two workarounds, both kinda stink:

1. Have the homepage's targetpage be something else than index.html.
2. Have the directory for the homepage's sub-pages and attachments be something else than index.

I doubt either of those can be implemented without ugly special casing. Any other idea? --intrigeri

As I understand it, this is how you'd do it with type maps:

• turn off MultiViews
• AddHandler type-map .var
• DirectoryIndex index.var
• make index.var a typemap (text file) pointing to index.en.html, index.fr.html, etc.

I'm not sure how well that fits into IkiWiki's structure, though; perhaps the master language could be responsible for generating the type-map on behalf of all slave languages, or something?

Another possibility would be to use filenames like index.html.en and index.html.fr, and set DirectoryIndex index.html? This could get problematic for languages whose ISO codes conventionally mean something else as extensions (Polish, .pl, is the usual example, since many sites interpret .pl as "this is a (Perl) CGI"). --smcv

There is something to be said about "index/foo" being really ugly and perhaps it would be nice to use something else. There does not appear to even be one function that could be changed; "$page/foo" is hardwired into ikiwiki in many places as a place to dump subsidiary content -- and it's not even consistent, since there is also eg, "$page.rss". I agree, approaching it from this direction would be a mess or a lot of work.

Type maps seem like a valid option, but also a lot of clutter.

index.html.pl does seem to be asking for trouble, even if apache can be configured to DTRT. It would make serving actual up perl scripts hard, at least. But that is some good out of the box thinking.. perhaps "index.foo.pl.html"?

However, that would mean that web servers need to be configured differently to serve translated and non-translated sites. The current apache configuration for po can be used with non-po sites and they still work. --Joey

I am vulnerable to the same problem because I use MultiViews, though I don't use the po module; I have to serve both Australian English and American English for my company's website (for SEO purposes; certain words that relate to our products are spelt differently in US and Australian English, and we need to be able to be googled with both spellings). I'm just fortunate that nobody has thought to add attachments to the front page yet. I raise this to point out that this is going to be a recurring problem that won't necessarily be fixed by changing the po module in isolation.

One could argue that "index" is already a special case, since it is the top page of the site. Things like parentlinks already use a special case for the top page (checking the variable HAS_PARENTLINKS). Likewise, when --usedirs is true, index is treated as a special case, since it generates "index.html" and not "index/index.html".

Unfortunately, I'm not sure what the best approach to solving this would be. --KathrynAndersen