From: Joey Hess Date: Sat, 31 Jul 2010 19:55:31 +0000 (-0400) Subject: Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/commitdiff_plain/b766ff004489467fb5a076f90f05bc2ac5dc8acf?hp=fee00fdb7a4ebb52e90f739cca33def70497620e Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info --- diff --git a/doc/bugs/po:_double_commits_of_po_files.mdwn b/doc/bugs/po:_double_commits_of_po_files.mdwn new file mode 100644 index 000000000..a871785be --- /dev/null +++ b/doc/bugs/po:_double_commits_of_po_files.mdwn @@ -0,0 +1,19 @@ +When adding a new english page, the po files are created, committed, +and then committed again. The second commit makes this change: + + -"Content-Type: text/plain; charset=utf-8\n" + -"Content-Transfer-Encoding: ENCODING" + +"Content-Type: text/plain; charset=UTF-8\n" + +"Content-Transfer-Encoding: ENCODING\n" + +Same thing happens when a change to an existing page triggers a po file +update. --[[Joey]] + +> * The s/utf-8/UTF-8 part has been fixed. +> * The ENCODING\n part is due to an inconsistency in po4a, which +> I've just send a patch for. --[[intrigeri]] + +>> I resubmitted the patch to po4a upstream, sending it this time to +>> their mailing-list: +>> [post archive](http://lists.alioth.debian.org/pipermail/po4a-devel/2010-July/001897.html). +>> --[[intrigeri]] diff --git a/doc/bugs/po:_new_pages_not_translatable.mdwn b/doc/bugs/po:_new_pages_not_translatable.mdwn new file mode 100644 index 000000000..84156bacc --- /dev/null +++ b/doc/bugs/po:_new_pages_not_translatable.mdwn @@ -0,0 +1,10 @@ +Today I added a new English page to l10n.ikiwiki.info. When I saved, +the page did not have the translation links at the top. I waited until +the po plugin had, in the background, created the po files, and refreshed; +still did not see the translation links. Only when I touched the page +source and refreshed did it finally add the translation links. +I can reproduce this bug in a test site. --[[Joey]] + +> I could reproduce this bug at some point during the merge of a buggy +> version of my ordered slave languages patch, but I cannot anymore. +> Could you please try again? --[[intrigeri]] diff --git a/doc/bugs/po:_ugly_messages_with_empty_files.mdwn b/doc/bugs/po:_ugly_messages_with_empty_files.mdwn new file mode 100644 index 000000000..d3992b6bc --- /dev/null +++ b/doc/bugs/po:_ugly_messages_with_empty_files.mdwn @@ -0,0 +1,6 @@ +If there are empty .mdwn files, the po plugin displays some ugly messages. + +> This is due to a bug in po4a (not checking definedness of a +> variable). One-liner patch sent. --[[intrigeri]] + +>> This seems to be fixed in po4a 0.40 => [[done]]. --[[intrigeri]] diff --git a/doc/forum/report_pagination.mdwn b/doc/forum/report_pagination.mdwn new file mode 100644 index 000000000..d609fd502 --- /dev/null +++ b/doc/forum/report_pagination.mdwn @@ -0,0 +1,11 @@ +I am thinking of adding pagination to the [[plugins/contrib/report]] plugin, but I'm not sure which is the best approach to take. (By "pagination" I mean breaking up a report into multiple pages with N entries per page.) + +Approaches: + +1. generate additional HTML files on the fly which are placed in the sub-directory for the page the report is on. These are not "pages", they are not under revision control, they aren't in the %pagesources hash etc. But using the `will_render` mechanism assures that they will be removed when they are no longer needed. + +2. create new pages which each have a report directive which shows a subset of the full result; add them to revision control, treat them as full pages. Problems with this are: (a) trying to figure out when to create these new pages and when not to, (b) whether or not these pages can be deleted automatically. + +3. some other approach I haven't thought of. + +I'm afraid that whatever approach I take, it will end up being a kludge. diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index 5088677c1..ac2df2d18 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -198,7 +198,7 @@ enabled, "slave" pages therefore link to the "master" page's discussion page. Likewise, "slave" pages are not supposed to have sub-pages; -[[WikiLinks|wikilink]] that appear on a "slave" page therefore link to +[[WikiLinks|ikiwiki/wikilink]] that appear on a "slave" page therefore link to the master page's sub-pages. Translating @@ -235,106 +235,20 @@ When using po4a older than 0.35, it is recommended to uninstall `Text::WrapI18N` (Debian package `libtext-wrapi18n-perl`), in order to avoid a potential denial of service. -TODO +BUGS ==== -Better links ------------- - -Once the fix to -[[bugs/pagetitle_function_does_not_respect_meta_titles]] from -[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the -generated links' text will be optionally based on the page titles set -with the [[meta|plugins/meta]] plugin, and will thus be translatable. -It will also allow displaying the translation status in links to slave -pages. Both were implemented, and reverted in commit -ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted -once [[intrigeri]]'s `meta` branch is merged. - -An integration branch, called `meta-po`, merges [[intrigeri]]'s `po` -and `meta` branches, and thus has this additional features. - -Language display order ----------------------- - -Jonas pointed out that one might want to control the order that links to -other languages are listed, for various reasons. Currently, there is no -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]] - -> Done in my po branch, preserving backward compatibility. Please -> review :) --[[intrigeri]] - ->> Right, well my immediate concern is that using an array to hold ->> hash-like pairs is not very clear to the user. It will be displayed ->> in a confusing way by websetup; dumping a setup file will probably ->> also cause it to be formatted in a confusing way. And the code ->> seems to assume that the array length is even, and probably blows ->> up if it is not.. and the value is marked safe so websetup can be ->> used to modify it and break that way too. --[[Joey]] - ->>> I have added a sanity check for the even array problem. This was ->>> the easy part. ->>> ->>> About the hash-like vs. dump and websetup issue, ->>> I can think of a few solutions: ->>> ->>> - keep the current hash-like pairs and unmark this setting as safe ->>> for websetup: this does not solve the dump setup issue, though; ->>> - replace the array of pairs with an array of ->>> "LANGUAGECODE|LANGUAGENAME" elements, using a pipe or whatever ->>> separator seems adequate; ->>> - add support for ordered hashes to `$config`, websetup and ->>> dumpsetup, using Tie-IxHash or any similar module; ->>> - replace the array of hash-like pairs with an array of real ->>> pairs, such as `[ ['de', 'Deutsch'], ['fr', 'Français'] ]`; this ->>> brings once again the need for `$config` to support arrays of ->>> arrays, which I have already implemented in my mirrorlist branch ->>> (see [[todo/mirrorlist_with_per-mirror_usedirs_settings]] for ->>> details). ->>> ->>> Joey, which of these solutions do you prefer? Or another one? ->>> I tend to prefer the last one. --[[intrigeri]] - ->>>> I prefer the pipe separator, I think. I'm concerned that there is ->>>> no way to really sanely represent complex data structures in web ->>>> setup. --[[Joey]] - ->>>>> Implemented using the pipe separator, fixed the po.t test suite ->>>>> accordingly. Please have a look. --[[intrigeri]] +[[!inline pages="bugs/po:* and !bugs/done and !link(bugs/done) and !bugs/*/*" +feeds=no actions=no archive=yes show=0]] ->>>>>> Merged. I wonder if "ll: Lang" would be better than pipe? - ->>>>>>> I've no clear opinion on this one. --[[intrigeri]] - ->>>>>> Also, the compatability code for HASH is not really needed, ->>>>>> ikiwiki has not been released using a hash for it. --[[Joey]] - ->>>>>>> The compatibility code is there to support the ->>>>>>> `po_slave_languages => {fr => 'Français'}` format that has ->>>>>>> been supported for ages. It's not there to support the ->>>>>>> intermediate array of hash-like pairs I proposed in the ->>>>>>> meantime. ->>>>>>> ->>>>>>> By the way, could you please have a look to the rest of my po ->>>>>>> branch? (bb22e8c4a..d98296d1db0) --[[intrigeri]] - ->>>>>>>> Thought I'd already merged everything; I've got those in now. ->>>>>>>> --[[Joey]] - -Pagespecs ---------- +TODO +==== -I was suprised that, when using the map directive, a pagespec of "*" -listed all the translated pages as well as regular pages. That can -make a big difference to an existing wiki when po is turned on, -and seems generally not wanted. -(OTOH, you do want to match translated pages by -default when locking pages.) --[[Joey]] +[[!inline pages="todo/po:* and !todo/done and !link(todo/done) and !todo/*/*" +feeds=no actions=no archive=yes show=0]] -Edit links on untranslated pages --------------------------------- +l10n wiki misconfiguration +-------------------------- If a page is not translated yet, the "translated" version of it displays wikilinks to other, existing (but not yet translated?) @@ -359,57 +273,32 @@ underlay, and the underlays lack translation to a given language. >> Compare with eg, the 100% translated Dansk version, where >> the WikiLink link links to the English WikiLink page. --[[Joey]] -Double commits of po files --------------------------- - -When adding a new english page, the po files are created, committed, -and then committed again. The second commit makes this change: - - -"Content-Type: text/plain; charset=utf-8\n" - -"Content-Transfer-Encoding: ENCODING" - +"Content-Type: text/plain; charset=UTF-8\n" - +"Content-Transfer-Encoding: ENCODING\n" - -Same thing happens when a change to an existing page triggers a po file -update. --[[Joey]] - -> * The s/utf-8/UTF-8 part has been fixed. -> * The ENCODING\n part is due to an inconsistency in po4a, which -> I've just send a patch for. --[[intrigeri]] - -New pages not translatable --------------------------- - -Today I added a new English page to l10n.ikiwiki.info. When I saved, -the page did not have the translation links at the top. I waited until -the po plugin had, in the background, created the po files, and refreshed; -still did not see the translation links. Only when I touched the page -source and refreshed did it finally add the translation links. -I can reproduce this bug in a test site. --[[Joey]] - -Ugly messages with empty files ------------------------------- - -If there are empty .mdwn files, the po plugin displays some ugly messages. - -> This is due to a bug in po4a (not checking definedness of a -> variable). One-liner patch sent. --[[intrigeri]] - -Translation of directives -------------------------- - -If a translated page contains a directive, it may expand to some english -text, or text in whatever single language ikiwiki is configured to "speak". - -Maybe there could be a way to switch ikiwiki to speaking another language -when building a non-english page? Then the directives would get translated. - -(We also will need this in order to use translated templates, when they are -available.) - -Documentation -------------- - -Maybe write separate documentation depending on the people it targets: -translators, wiki administrators, hackers. This plugin may be complex -enough to deserve this. +>>> Seems not related to the page/string translation status: the 0% +>>> translated Spanish version has the correct link, just like the +>>> Dansk version => I'm changing the bug title accordingly. +>>> +>>> I tested forcing the sv html page to be rebuilt by translating a +>>> string in it, it did not fix the bug. I did the same for the +>>> Spanish page, it did not introduce the bug. So this is really +>>> weird. +>>> +>>> The smiley underlay seems to be the only place where the wrong +>>> thing happens: the basewiki underlay has similar examples +>>> that do not exhibit this bug. An underlay linking to another might +>>> be necessary to reproduce it. Going to dig deeper. --[[intrigeri]] + +>>>> After a few hours lost in the Perl debugger, I think I have found +>>>> the root cause of the problem: in l10n wiki's configured +>>>> `underlaydir`, the basewiki is present in every slave language +>>>> that is enabled for this wiki *but* Swedish. With such a +>>>> configuration, the `ikiwiki/wikilink` page indeed does not exist +>>>> in Swedish language: no `ikiwiki/wikilink.sv.po` can be found +>>>> where ikiwiki is looking. Have a look to +>>>> , the basewiki is not +>>>> available in Swedish language on this wiki. So this is not a po +>>>> bug, but a configuration or directories layout issue. This is +>>>> solved by adding the Swedish basewiki to the underlay dir, which +>>>> is I guess not a possibility in the l10n wiki context. I guess +>>>> this could be solved by adding `SRCDIR/basewiki` as an underlay +>>>> to your l10n wiki configuration, possibly using the +>>>> `add_underlays` configuration directive. --[[intrigeri]] diff --git a/doc/plugins/po/discussion.mdwn b/doc/plugins/po/discussion.mdwn index 73858c818..50998e822 100644 --- a/doc/plugins/po/discussion.mdwn +++ b/doc/plugins/po/discussion.mdwn @@ -644,28 +644,6 @@ daring a timid "please pull"... or rather, please review again :) >>> 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 diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn new file mode 100644 index 000000000..78e8e3ade --- /dev/null +++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn @@ -0,0 +1,32 @@ +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]] + +>>>> I eventually did, and got rid of the ugly double rebuild of pages +>>>> at build time. This involved adding a `rescan` hook. Rationale +>>>> and details are in my po branch commit messages. I believe this +>>>> new way of handling meta title escaping to be far more robust. +>>>> Moreover this new implementation is more generic, feels more +>>>> logical to me, and probably fixes other similar bugs outside the +>>>> meta plugin scope. Please have a look when you can. +>>>> --[[intrigeri]] diff --git a/doc/todo/po:_better_documentation.mdwn b/doc/todo/po:_better_documentation.mdwn new file mode 100644 index 000000000..6e9804df4 --- /dev/null +++ b/doc/todo/po:_better_documentation.mdwn @@ -0,0 +1,3 @@ +Maybe write separate documentation for the po plugin, depending on the +people it targets: translators, wiki administrators, hackers. This +plugin may be complex enough to deserve this. diff --git a/doc/todo/po:_better_links.mdwn b/doc/todo/po:_better_links.mdwn new file mode 100644 index 000000000..af879a56a --- /dev/null +++ b/doc/todo/po:_better_links.mdwn @@ -0,0 +1,12 @@ +Once the fix to +[[bugs/pagetitle_function_does_not_respect_meta_titles]] from +[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the +generated links' text will be optionally based on the page titles set +with the [[meta|plugins/meta]] plugin, and will thus be translatable. +It will also allow displaying the translation status in links to slave +pages. Both were implemented, and reverted in commit +ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted +once [[intrigeri]]'s `meta` branch is merged. + +An integration branch, called `meta-po`, merges [[intrigeri]]'s `po` +and `meta` branches, and thus has this additional features. diff --git a/doc/todo/po:_better_translation_interface.mdwn b/doc/todo/po:_better_translation_interface.mdwn new file mode 100644 index 000000000..e66a77b85 --- /dev/null +++ b/doc/todo/po:_better_translation_interface.mdwn @@ -0,0 +1,2 @@ +Add a message-by-message translation interface to the PO plugin, +with automatic escaping of special chars. diff --git a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn new file mode 100644 index 000000000..4ddd0fa1e --- /dev/null +++ b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn @@ -0,0 +1,2 @@ +ikiwiki now has a `disable` hook. Should the po plugin remove the po +files from the source repository when it has been disabled? diff --git a/doc/todo/po:_rethink_pagespecs.mdwn b/doc/todo/po:_rethink_pagespecs.mdwn new file mode 100644 index 000000000..50c10c5db --- /dev/null +++ b/doc/todo/po:_rethink_pagespecs.mdwn @@ -0,0 +1,11 @@ +I was suprised that, when using the map directive, a pagespec of "*" +listed all the translated pages as well as regular pages. That can +make a big difference to an existing wiki when po is turned on, +and seems generally not wanted. +(OTOH, you do want to match translated pages by +default when locking pages.) --[[Joey]] + +> Seems hard to me to sort apart the pagespec whose matching pages +> list must be restricted to pages in the master (or current?) +> language, and the ones that should not. The only solution I can see +> to this surprising behaviour is: documentation. --[[intrigeri]] diff --git a/doc/todo/po:_translation_of_directives.mdwn b/doc/todo/po:_translation_of_directives.mdwn new file mode 100644 index 000000000..89fc93620 --- /dev/null +++ b/doc/todo/po:_translation_of_directives.mdwn @@ -0,0 +1,8 @@ +If a translated page contains a directive, it may expand to some english +text, or text in whatever single language ikiwiki is configured to "speak". + +Maybe there could be a way to switch ikiwiki to speaking another language +when building a non-english page? Then the directives would get translated. + +(We also will need this in order to use translated templates, when they are +available.)