From: Joey Hess Date: Thu, 27 Aug 2009 19:51:55 +0000 (-0400) Subject: Merge commit 'intrigeri/po' X-Git-Tag: 3.1415926~42 X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/commitdiff_plain/023c3046c0d5d595fd92c535842bf05fb0da0955?hp=cdc3576c8d1efb2593cac2d9da3f2393a2afe26e Merge commit 'intrigeri/po' --- diff --git a/debian/changelog b/debian/changelog index 69e197e37..9f10c2913 100644 --- a/debian/changelog +++ b/debian/changelog @@ -29,6 +29,7 @@ ikiwiki (3.1415926) UNRELEASED; urgency=low * Rebuild wikis on upgrade to this version to fix bloat caused by the dependency bug. * htmltidy: Print a warning message if tidy fails. Closes: #543722 + * po: Fix name of translated toplevel index page. (intrigeri) -- Joey Hess Wed, 12 Aug 2009 12:25:30 -0400 diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index 65573b877..f020adac2 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -265,9 +265,20 @@ good reason for that to be done? --[[Joey]] > The commit 0113c69d4fb in my po branch might fix this. --[[intrigeri]] >> It may fix it in passing, but shouldn't it also be fixed for the other ->> `po_link_to` styles? (Also, if `mybestlink` is going to always ->> just return `bestlink` in this case, there seems no reason to inject ->> it.) --[[Joey]] +>> `po_link_to` styles? + +>>> Other `po_link_to` styles already work ok: say there is +>>> a \[[dest]] link on a page called `dest`. When rendering +>>> `dest.LL`, `mybestlink` returns `dest.LL`, and `htmllink` is then +>>> able to detect, and manage correctly, that it is a self-link. +>>> --[[intrigeri]] + +>> (Also, if `mybestlink` is going to always just return `bestlink` in +>> this case, there seems no reason to inject it.) --[[Joey]] + +>>> Right. Commit cdc3576c8d1efb2 in my po branch prevents +>>> `mybestlink` to be injected when `po_link_to` is +>>> `default`. --[[intrigeri]] Language display order ---------------------- @@ -278,47 +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]] - -Name of toplevel index page ---------------------------- - -Normally at the top index page of a wiki, you see the wiki name at -the top. However, at the top *translated* index page, you see something -like "index.da". --[[Joey]] - -> I suggest changing `Render.pm`, line 115, to replace the `$page eq 'index'` -> test with a predicate call such as isindexpage($page). Such a predicate -> function could then be overriden by the po plugin. --[[intrigeri]] - ->> Could do that, but if you have such a function it's natural to want to ->> use it elsewhere. Not clear to me it would make sense for po to override ->> such a function if it were used in some of the other places that compare ->> to index. ->> ->> The other option would be for po to override the template setting. ->> --[[Joey]] - Pagespecs --------- 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]]