-Security checks
----------------
-
-- Can any sort of directives be put in po files that will
- cause mischief (ie, include other files, run commands, crash gettext,
- whatever). The [PO file
- format](http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files)
- should contain the answer.
-- Any security issues on running po4a on untrusted content?
-
-### Security history
-
-#### GNU gettext
-- [CVE-2004-0966](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966)
- / [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.
-
-#### po4a
--
- [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.
-
-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.
+
+Language display order
+----------------------
+
+Jonas pointed out that one might want to control the order that links to
+other languages are listed, for various reasons. Currently, there is no
+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]]
+
+>> Right, well my immediate concern is that using an array to hold
+>> hash-like pairs is not very clear to the user. It will be displayed
+>> in a confusing way by websetup; dumping a setup file will probably
+>> also cause it to be formatted in a confusing way. And the code
+>> seems to assume that the array length is even, and probably blows
+>> up if it is not.. and the value is marked safe so websetup can be
+>> used to modify it and break that way too. --[[Joey]]
+
+>>> I have added a sanity check for the even array problem. This was
+>>> the easy part.
+>>>
+>>> About the hash-like vs. dump and websetup issue,
+>>> I can think of a few solutions:
+>>>
+>>> - keep the current hash-like pairs and unmark this setting as safe
+>>> for websetup: this does not solve the dump setup issue, though;
+>>> - replace the array of pairs with an array of
+>>> "LANGUAGECODE|LANGUAGENAME" elements, using a pipe or whatever
+>>> separator seems adequate;
+>>> - add support for ordered hashes to `$config`, websetup and
+>>> dumpsetup, using Tie-IxHash or any similar module;
+>>> - replace the array of hash-like pairs with an array of real
+>>> pairs, such as `[ ['de', 'Deutsch'], ['fr', 'Français'] ]`; this
+>>> brings once again the need for `$config` to support arrays of
+>>> arrays, which I have already implemented in my mirrorlist branch
+>>> (see [[todo/mirrorlist_with_per-mirror_usedirs_settings]] for
+>>> details).
+>>>
+>>> Joey, which of these solutions do you prefer? Or another one?
+>>> I tend to prefer the last one. --[[intrigeri]]
+
+>>>> I prefer the pipe separator, I think. I'm concerned that there is
+>>>> no way to really sanely represent complex data structures in web
+>>>> setup. --[[Joey]]
+
+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]]
+
+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