X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/1194584dad1a8326161658e5a5b1c7980d75023f..ec965fc92cd41f597c6e8e88584b9a688407c8c6:/doc/plugins/contrib/po.mdwn diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/contrib/po.mdwn index 8b19afae6..665e48343 100644 --- a/doc/plugins/contrib/po.mdwn +++ b/doc/plugins/contrib/po.mdwn @@ -153,6 +153,14 @@ Any thoughts on this? >> basewiki, which seems like it should be pretty easy to do, and would be >> a great demo! --[[Joey]] >> +>>> I have a complete translation of basewiki into danish, and am working with +>>> others on preparing one in german. For a complete translated user +>>> experience, however, you will also need templates translated (there are a few +>>> translatable strings there too). My not-yet-merged po4a Markdown improvements +>>> (see [bug#530574](http://bugs.debian.org/530574)) correctly handles multiple +>>> files in a single PO which might be relevant for template translation handling. +>>> --[[JonasSmedegaard]] +>> >>> I've merged your changes into my own branch, and made great >>> progress on the various todo items. Please note my repository >>> location has changed a few days ago, my user page was updated @@ -320,3 +328,127 @@ finish it at some point in the first quarter of 2009. --[[intrigeri]] >> --[[intrigeri]] > > --[[Joey]] + +I reverted the `%backlinks` and `$backlinks_calculated` exposing. +The issue they were solving probably will arise again when I'll work +on my meta branch again (i.e. when the simplified po one is merged), +but the po thing is supposed to work without these ugly `our`. +Seems like it was the last unaddressed item from Joey's review, so I'm +daring a timid "please pull"... or rather, please review again :) +--[[intrigeri]] + +> Ok, I've reviewed and merged into my own po branch. It's looking very +> mergeable. +> +> * Is it worth trying to fix compatability with `indexpages`? +>> +>> Supporting `usedirs` being enabled or disabled was already quite +>> hard IIRC, so supporting all four combinations of `usedirs` and +>> `indexpages` settings will probably be painful. I propose we forget +>> about it until someone reports he/she badly needs it, and then +>> we'll see what can be done. +>> +> * Would it make sense to go ahead and modify `page.tmpl` to use +> OTHERLANGUAGES and PERCENTTRANSLATED, instead of documenting how to modify it? +>> +>> Done in my branch. +>> +> * Would it be better to disable po support for pages that use unsupported +> or poorly-supported markup languages? +> +>> I prefer keeping it enabled, as: +>> +>> * most wiki markups "almost work" +>> * when someone needs one of these to be fully supported, it's not +>> that hard to add dedicated support for it to po4a; if it were +>> disabled, I fear the ones who could do this would maybe think +>> it's blandly impossible and give up. +>> + +> * What's the reasoning behind checking that the link plugin +> is enabled? AFAICS, the same code in the scan hook should +> also work when other link plugins like camelcase are used. +>> +>> That's right, fixed. +>> +> * In `pagetemplate` there is a comment that claims the code +> relies on `genpage`, but I don't see how it does; it seems +> to always add a discussion link? +>> +>> It relies on IkiWiki::Render's `genpage` as this function sets the +>> `discussionlink` template param iff it considers a discussion link +>> should appear on the current page. That's why I'm testing +>> `$template->param('discussionlink')`. +>> +>>> Maybe I was really wondering why it says it could lead to a broken +>>> link if the cgiurl is disabled. I think I see why now: Discussionlink +>>> will be set to a link to an existing disucssion page, even if cgi is +>>> disabled -- but there's no guarantee of a translated discussion page +>>> existing in that case. *However*, htmllink actually checks +>>> for this case, and will avoid generating a broken link so AFAICS, the +>>> comment is actually innacurate.. what will really happen in this case +>>> is discussionlink will be set to a non-link translation of +>>> "discussion". Also, I consider `$config{cgi}` and `%links` (etc) +>>> documented parts of the plugin interface, which won't change; po could +>>> rely on them to avoid this minor problem. --[[Joey]] +>>>> +>>>> Done in my branch. --[[intrigeri]] +>>>> +> +> * Is there any real reason not to allow removing a translation? +> I'm imagining a spammy translation, which an admin might not +> be able to fix, but could remove. +>> +>> On the other hand, allowing one to "remove" a translation would +>> probably lead to misunderstandings, as such a "removed" translation +>> page would appear back as soon as it is "removed" (with no strings +>> translated, though). I think an admin would be in a position to +>> delete the spammy `.po` file by hand using whatever VCS is in use. +>> Not that I'd really care, but I am slightly in favour of the way +>> it currently works. +>> +>>> That would definitly be confusing. It sounds to me like if we end up +>>> needing to allow web-based deletion of spammy translations, it will +>>> need improvements to the deletion UI to de-confuse that. It's fine to +>>> put that off until needed --[[Joey]] +>> +> * Re the meta title escaping issue worked around by `change`. +> I suppose this does not only affect meta, but other things +> at scan time too. Also, handling it only on rebuild feels +> suspicious -- a refresh could involve changes to multiple +> pages and trigger the same problem, I think. Also, exposing +> this rebuild to the user seems really ugly, not confidence inducing. +> +> So I wonder if there's a better way. Such as making po, at scan time, +> re-run the scan hooks, passing them modified content (either converted +> from po to mdwn or with the escaped stuff cheaply de-escaped). (Of +> course the scan hook would need to avoid calling itself!) +> +> (This doesn't need to block the merge, but I hope it can be addressed +> eventually..) +> +> --[[Joey]] +>> +>> I'll think about it soon. +>> +>> --[[intrigeri]] +>> +>>> Did you get a chance to? --[[Joey]] + + * As discussed at [[todo/l10n]] the templates needs to be translatable too. They + should be treated properly by po4a using the markdown option - at least with my + later patches in [bug#530574](http://bugs.debian.org/530574)) applied. + + * It seems to me that the po plugin (and possibly other parts of ikiwiki) wrongly + uses gettext. As I understand it, gettext (as used currently in ikiwiki) always + lookup a single language, That might make sense for a single-language site, but + multilingual sites should emit all strings targeted at the web output in each own + language. + + So generally the system language (used for e.g. compile warnings) should be separated + from both master language and slave languages. + + Preferrably the gettext subroutine could be extended to pass locale as optional + secondary parameter overriding the default locale (for messages like "N/A" as + percentage in po plugin). Alternatively (with above mentioned template support) + all such strings could be externalized as templates that can then be localized.