From ffcd97ce52edd73f092d15aae89bbacad99b38b6 Mon Sep 17 00:00:00 2001 From: Joey Hess 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