-Security checks
----------------
-
-### Security history
-
-The only past security issues I could find in GNU gettext and po4a
-are:
-
-- [CVE-2004-0966](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966),
- *i.e.* [Debian bug #278283](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278283):
- the autopoint and gettextize scripts in the GNU gettext package
- 1.14 and later versions, as used in Trustix Secure Linux 1.5
- through 2.1 and other operating systems, allows local users to
- overwrite files via a symlink attack on temporary files.
-- [CVE-2007-4462](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462):
- `lib/Locale/Po4a/Po.pm` in po4a before 0.32 allows local users to
- overwrite arbitrary files via a symlink attack on the
- gettextization.failed.po temporary file.
-
-**FIXME**: check whether this plugin would have been a possible attack
-vector to exploit these vulnerabilities.
-
-Depending on my mood, the lack of found security issues can either
-indicate that there are none, or reveal that no-one ever bothered to
-find (and publish) them.
-
-### PO file features
-
-Can any sort of directives be put in po files that will cause mischief
-(ie, include other files, run commands, crash gettext, whatever)?
-
-> No [documented](http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files)
-> directive is supposed to do so.
-
-### Running po4a on untrusted content
-
-Are there any security issues on running po4a on untrusted content?
-
-> To say the least, this issue is not well covered, at least publicly:
->
-> - the documentation does not talk about it;
-> - grep'ing the source code for `security` or `trust` gives no answer.
->
-> I'll ask their opinion to the po4a maintainers.
->
-> I'm not in a position to audit the code, but I had a look anyway:
->
-> - no use of `system()`, `exec()` or backticks in `Locale::Po4a`; are
-> there any other way to run external programs in Perl?
-> - a symlink attack vulnerability was already discovered, so I "hope"
-> the code has been checked to find some more already
-> - the po4a parts we are using themselves use the following Perl
-> modules: `DynaLoader`, `Encode`, `Encode::Guess`,
-> `Text::WrapI18N`, `Locale::gettext` (`bindtextdomain`,
-> `textdomain`, `gettext`, `dgettext`)
->
-> --[[intrigeri]]
-
-### Fuzzing input
-
-I was not able to find any public information about gettext or po4a
-having been tested with a fuzzing program, such as `zzuf` or `fusil`.
-Moreover, some gettext parsers seem to be quite
-[easy to crash](http://fusil.hachoir.org/trac/browser/trunk/fuzzers/fusil-gettext),
-so it might be useful to bang gettext/po4a's heads against such
-a program in order to easily detect some of the most obvious DoS.
-[[--intrigeri]]
-
-gettext/po4a rough corners
+Better links
+------------
+
+Once the fix to
+[[bugs/pagetitle_function_does_not_respect_meta_titles]] from
+[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the
+generated links' text will be optionally based on the page titles set
+with the [[meta|plugins/meta]] plugin, and will thus be translatable.
+It will also allow displaying the translation status in links to slave
+pages. Both were implemented, and reverted in commit
+ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted
+once [[intrigeri]]'s `meta` branch is merged.
+
+An integration branch, called `meta-po`, merges [[intrigeri]]'s `po`
+and `meta` branches, and thus has this additional features.
+
+Pagespecs
+---------
+
+I was suprised that, when using the map directive, a pagespec of "*"
+listed all the translated pages as well as regular pages. That can
+make a big difference to an existing wiki when po is turned on,
+and seems generally not wanted.
+(OTOH, you do want to match translated pages by
+default when locking pages.) --[[Joey]]
+
+> Seems hard to me to sort apart the pagespec whose matching pages
+> 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]]
+
+Edit links on untranslated pages
+--------------------------------
+
+If a page is not translated yet, the "translated" version of it
+displays wikilinks to other, existing (but not yet translated?)
+pages as edit links, as if those pages do not exist.
+
+That's really confusing, especially as clicking such a link
+brings up an edit form to create a new, english page.
+
+This is with po_link_to=current or negotiated. With default, it doesn't
+happen..
+
+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]]
+
+>> Sure, go here <http://l10n.ikiwiki.info/smiley/smileys/index.sv.html>
+>> (Currently 0% translateed) and see the 'WikiLink' link at the bottom,
+>> which goes to <http://l10n.ikiwiki.info/ikiwiki.cgi?page=ikiwiki/wikilink&from=smiley/smileys&do=create>
+>> Compare with eg, the 100% translated Dansk version, where
+>> the WikiLink link links to the English WikiLink page. --[[Joey]]
+
+Double commits of po files