further thought
authorJoey Hess <joey@kitenet.net>
Mon, 13 Sep 2010 19:11:46 +0000 (15:11 -0400)
committerJoey Hess <joey@kitenet.net>
Mon, 13 Sep 2010 19:11:46 +0000 (15:11 -0400)
doc/todo/po:_rethink_pagespecs.mdwn

index 50c10c5dbb78066db14787aa09b87c8e58634a7c..ada372b0e798419a955dd5e5f0ecdafe4fb54f50 100644 (file)
@@ -9,3 +9,27 @@ default when locking pages.) --[[Joey]]
 > list must be restricted to pages in the master (or current?)
 > language, and the ones that should not. The only solution I can see
 > to this surprising behaviour is: documentation. --[[intrigeri]]
+
+>> Well, a sorting criteria might be that if a PageSpec is used
+>> with a specified locaction, as happens whenever a PageSpec is
+>> used on a page, then it should match only `currentlang()`. If it 
+>> is used without a location, as in the setup file, then no such limit.
+>> 
+>> Note that
+>> `match_currentlang` currently dies if called w/o a location -- if
+>> it instead was always true w/o a location, this would just mean that
+>> all pagespecs should have `and currentlang()` added to them. How to
+>> implement that? All I can think of doing is wrapping
+>> `pagespec_translate`.
+>>
+>> The only case I've found where it does make sense to match other
+>> language pages is on `l10n.ikiwiki.info` when listing pages that
+>> need translation.
+>> 
+>> Otherwise, it can be documented, but that's not really enough;
+>> a user who makes a site using auto-blog.setup and enables po will
+>> get a really scred up blog that lists translations as separate posts
+>> and needs significant work to fix. I have thought about making
+>> `match_currentlang` a stub in IkiWiki, so I can use it in all
+>> the PageSpecs in the example blog, but I can't say I love the idea.
+>> --[[Joey]]