(no commit message)

[git.ikiwiki.info.git] / doc / plugins / po / discussion.mdwn

diff --git a/doc/plugins/po/discussion.mdwn b/doc/plugins/po/discussion.mdwn
index 6a7bb7f4bbf073aa4ca134327be139f8b8147d3b..a123935462a2b76ef8d348890c9a3edfb2aaf900 100644 (file)
--- a/doc/plugins/po/discussion.mdwn
+++ b/doc/plugins/po/discussion.mdwn
@@ -150,6 +150,23 @@ The following analysis was done with his help.
   variables; according to [[Joey]], this is "Freaky code, but seems ok
   due to use of `quotementa`".
 
   variables; according to [[Joey]], this is "Freaky code, but seems ok
   due to use of `quotementa`".
 

+##### Locale::Po4a::Xhtml
+
+* does not run any external program
+* does not build regexp's from untrusted variables
+
+=> Seems safe as far as the `includessi` option is disabled; the po
+plugin explicitly disables it.
+
+Relies on Locale::Po4a::Xml` to do most of the work.
+
+##### Locale::Po4a::Xml
+
+* does not run any external program
+* the `includeexternal` option makes it able to read external files;
+  the po plugin explicitly disables it
+* untrusted variables are escaped when used to build regexp's
+

 ##### Text::WrapI18N
 
 `Text::WrapI18N` can cause DoS
 ##### Text::WrapI18N
 
 `Text::WrapI18N` can cause DoS


@@ -366,11 +383,13 @@ Any thoughts on this?
 >> basewiki, which seems like it should be pretty easy to do, and would be
 >> a great demo! --[[Joey]]
 >>
 >> 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
+>>> I have a complete translation of basewiki into danish, available merged into
+>>> ikiwiki at git://source.jones.dk/ikiwiki-upstream (branch underlay-da), 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
 >>> 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
+>>> translatable strings there too).  My most recent po4a Markdown improvements
+>>> adopted upstream but not yet in Debian (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]]
 >>
 >>> files in a single PO which might be relevant for template translation handling.
 >>> --[[JonasSmedegaard]]
 >>


@@ -511,7 +530,7 @@ finish it at some point in the first quarter of 2009. --[[intrigeri]]
 >>>>
 >>>>> Done. --[[intrigeri]]
 >>> 
 >>>>
 >>>>> Done. --[[intrigeri]]
 >>> 

-> * I'm very fearful of the `add_depends` in `postscan`. 
+> * I'm very fearful of the `add_depends` in `indexhtml`. 

 >   Does this make every page depend on every page that links
 >   to it? Won't this absurdly bloat the dependency pagespecs
 >   and slow everything down? And since nicepagetitle is given
 >   Does this make every page depend on every page that links
 >   to it? Won't this absurdly bloat the dependency pagespecs
 >   and slow everything down? And since nicepagetitle is given


@@ -625,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]] 
 >> 
 >>> 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
 
  * 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


@@ -697,3 +694,48 @@ 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**
 * 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]] 
+
+----
+# Failing to have currentlang respected when using inline
+I am trying to wrap my head around l10n with ikiwiki. Set up a test site, l10n is working fine. 
+Now when inlining a bunch of pages, no matter what inline template I use all links are
+going to the master language, the slave being ignored on all levels I tried. 
+
+Trying to use currentlang() inside the inline directive to force the current setting in ikiwiki.setup - I get **no pages or links** to pages at all.   
+\[[!inline pages=\"man/* and currentlang() and !*/sidebar and !*/b and !*.*\" template=\"inlinepage\" archive=\"yes\" quick=\"yes\" show=\"0\" sort=\"mtime\" reverse=\"no\"]]
+
+Turning meta title on slave translation pages on and off - **no change**.   
+Turning usedirs on and off - **no change**.   
+Testing with different inline templates - **no change**.   
+Trying the use of tags on the slave language pages - **tagged() doesn't match any tagged pages**.
+
+I tried everything I could think of being the cause.
+Could this be related to the templates used by inline not being localized?   
+Any hints wether I am currently running into some dead end with ikiwiki regarding template l10n here would be greatly appreciated.
+
+Besides: When using the map instead of the inline directive, regarding l10n all is working like it should, pitty is that for the kind of deployment I am heading for I will also need pages to be included with a custom template.