From ffcd97ce52edd73f092d15aae89bbacad99b38b6 Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@gnu.kitenet.net>
Date: Thu, 27 Aug 2009 15:49:12 -0400
Subject: change cherry-picked; move to discussion
---
doc/plugins/po.mdwn | 24 ------------------------
doc/plugins/po/discussion.mdwn | 25 +++++++++++++++++++++++++
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn
index 673bbf406..9c4d8ffbd 100644
--- a/doc/plugins/po.mdwn
+++ b/doc/plugins/po.mdwn
@@ -289,30 +289,6 @@ 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]]
-Duplicate %links ?
-------------------
-
-I notice code in the scan hook that seems to assume
-that %links will accumulate duplicate links for a page.
-That used to be so, but the bug was fixed. Does this mean
-that po might be replacing the only link on a page, in error?
---[[Joey]]
-
-> It would replace it. The only problematic case is when another
-> plugin has its own reasons, in its `scan` hook, to add a page
-> that is already there to `$links{$page}`. This other plugin's
-> effect might then be changed by po's `scan` hook... which could
-> be either good (better overall l10n) or bad (break the other
-> plugin's goal). --[[intrigeri]]
-
->> Right.. well, the cases where links are added is very small.
->> Grepping for `add_link`, it's just done by link, camelcase, meta, and
->> tag. All of these are supposed to work just link regular links
->> so I'd think that is ok. We could probably remove the currently scary
->> comment about only wanting to change the first link. --[[Joey]]
-
->>> Commit 3c2bffe21b91684 in my po branch does this. --[[intrigeri]]
-
Name of toplevel index page
---------------------------
diff --git a/doc/plugins/po/discussion.mdwn b/doc/plugins/po/discussion.mdwn
index 1c3f0e752..ab822e76c 100644
--- a/doc/plugins/po/discussion.mdwn
+++ b/doc/plugins/po/discussion.mdwn
@@ -699,3 +699,28 @@ and via CGI, have been tested.
* general test with `indexpages` enabled: **not OK**
* general test with `po_link_to=default` with `userdirs` enabled: **OK**
* general test with `po_link_to=default` with `userdirs` disabled: **OK**
+
+Duplicate %links ?
+------------------
+
+I notice code in the scan hook that seems to assume
+that %links will accumulate duplicate links for a page.
+That used to be so, but the bug was fixed. Does this mean
+that po might be replacing the only link on a page, in error?
+--[[Joey]]
+
+> It would replace it. The only problematic case is when another
+> plugin has its own reasons, in its `scan` hook, to add a page
+> that is already there to `$links{$page}`. This other plugin's
+> effect might then be changed by po's `scan` hook... which could
+> be either good (better overall l10n) or bad (break the other
+> plugin's goal). --[[intrigeri]]
+
+>> Right.. well, the cases where links are added is very small.
+>> Grepping for `add_link`, it's just done by link, camelcase, meta, and
+>> tag. All of these are supposed to work just link regular links
+>> so I'd think that is ok. We could probably remove the currently scary
+>> comment about only wanting to change the first link. --[[Joey]]
+
+>>> Commit 3c2bffe21b91684 in my po branch does this. --[[intrigeri]]
+>>>> Cherry-picked --[[Joey]]
--
cgit v1.2.3