+- a 21M file containing 100 concatenated copies of all the files in my
+ `/usr/share/common-licenses/`; I had no existing PO file or
+ translated versions at hand, which renders these tests
+ quite incomplete.
+- po4a was the Debian 0.34-2 package; the same tests were also run
+ after replacing the `Text` module with the CVS one (the core was not
+ changed in CVS since 0.34-2 was released), without any significant
+ difference in the results.
+- Perl 5.10.0-16
+
+#### po4a-gettextize
+
+`po4a-gettextize` uses more or less the same po4a features as our
+`refreshpot` function.
+
+Without specifying an input charset, zzuf'ed `po4a-gettextize` quickly
+errors out, complaining it was not able to detect the input charset;
+it leaves no incomplete file on disk.
+
+So I had to pretend the input was in UTF-8, as does the po plugin.
+
+Two ways of crashing were revealed by this command-line:
+
+ zzuf -vc -s 0:100 -r 0.1:0.5 \
+ po4a-gettextize -f text -o markdown -M utf-8 -L utf-8 \
+ -m LICENSES >/dev/null
+
+They are:
+
+ Malformed UTF-8 character (UTF-16 surrogate 0xdcc9) in substitution iterator at /usr/share/perl5/Locale/Po4a/Po.pm line 1443.
+ Malformed UTF-8 character (fatal) at /usr/share/perl5/Locale/Po4a/Po.pm line 1443.
+
+and
+
+ Malformed UTF-8 character (UTF-16 surrogate 0xdcec) in substitution (s///) at /usr/share/perl5/Locale/Po4a/Po.pm line 1443.
+ Malformed UTF-8 character (fatal) at /usr/share/perl5/Locale/Po4a/Po.pm line 1443.
+
+Perl seems to exit cleanly, and an incomplete PO file is written on
+disk. I not sure whether if this is a bug in Perl or in `Po.pm`.
+
+#### po4a-translate
+
+`po4a-translate` uses more or less the same po4a features as our
+`filter` function.
+
+Without specifying an input charset, same behaviour as
+`po4a-gettextize`, so let's specify UTF-8 as input charset as of now.
+
+ zzuf -cv \
+ po4a-translate -d -f text -o markdown -M utf-8 -L utf-8 \
+ -k 0 -m LICENSES -p LICENSES.fr.po -l test.fr
+
+... prints tons of occurences of the following error, but a complete
+translated document is written (obviously with some weird chars
+inside):
+
+ Use of uninitialized value in string ne at /usr/share/perl5/Locale/Po4a/TransTractor.pm line 854.
+ Use of uninitialized value in string ne at /usr/share/perl5/Locale/Po4a/TransTractor.pm line 840.
+ Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Locale/Po4a/Po.pm line 1002.
+
+While:
+
+ zzuf -cv -s 0:10 -r 0.001:0.3 \
+ po4a-translate -d -f text -o markdown -M utf-8 -L utf-8 \
+ -k 0 -m LICENSES -p LICENSES.fr.po -l test.fr
+
+... seems to lose the fight, at the `readpo(LICENSES.fr.po)` step,
+against some kind of infinite loop, deadlock, or any similar beast.
+It does not seem to eat memory, though.
+
+Whatever format module is used does not change anything. This is thus
+probably a bug in po4a's core or in a lib it depends on.
+
+The sub `read`, in `TransTractor.pm`, seems to be a good debugging
+starting point.
+
+#### msgmerge
+
+`msgmerge` is run in our `refreshpofiles` function. I did not manage
+to crash it with `zzuf`.
+
+gettext/po4a rough corners
+--------------------------
+
+- fix infinite loop when synchronizing two ikiwiki (when checkouts
+ live in different directories): say bla.fr.po has been updated in
+ repo2; pulling repo2 from repo1 seems to trigger a PO update, that
+ changes bla.fr.po in repo1; then pushing repo1 to repo2 triggers
+ a PO update, that changes bla.fr.po in repo2; etc.; quickly fixed in
+ `629968fc89bced6727981c0a1138072631751fee`, by disabling references
+ in Pot files. Using `Locale::Po4a::write_if_needed` might be
+ a cleaner solution. (warning: this function runs the external
+ `diff` program, have to check security)
+- new translations created in the web interface must get proper
+ charset/encoding gettext metadata, else the next automatic PO update
+ removes any non-ascii chars; possible solution: put such metadata
+ into the Pot file, and let it propagate; should be fixed in
+ `773de05a7a1ee68d2bed173367cf5e716884945a`, time will tell.
+
+Better links
+------------
+
+### Page title in links
+
+To use the page titles set with the [[meta|plugins/meta]] plugin when
+rendering links would be very much nicer, than the current
+"filename.LL" format. This is actually a duplicate for
+[[bugs/pagetitle_function_does_not_respect_meta_titles]].
+
+Going to work on this in my `meta` branch.
+
+### Translation status in links
+
+See [[contrib/po]].
+
+### Backlinks
+
+They are not updated when the source page changes (e.g. meta title).
+
+Page formats
+------------
+
+Markdown is well supported, great, but what about others?
+
+The [[po|plugins/po]] uses `Locale::Po4a::Text` for every page format;
+this can be expected to work out of the box with most other wiki-like
+formats supported by ikiwiki. Some of their ad-hoc syntax might be
+parsed in a strange way, but the worst problems I can imagine would be
+wrapping issues; e.g. there is code in po4a dedicated to prevent
+re-wrapping the underlined Markdown headers.
+
+While it would be easy to better support formats such as [[html]] or
+LaTeX, by using for each one the dedicated po4a module, this can be
+problematic from a security point of view.
+
+**TODO**: test the more popular formats and write proper documentation
+about it.