From kaloian at doganov.org  Sat Aug  4 23:31:11 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 05 Aug 2007 02:31:11 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
Message-ID: <87ps22ev28.fsf@doganov.org>

An embedded and charset-unspecified text was scrubbed...
Name: po4a-html-translatable-attribs.diff
Url: http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070805/ae427866/attachment.txt 

From nicolas.francois at centraliens.net  Sun Aug  5 17:00:35 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Sun, 5 Aug 2007 19:00:35 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <87ps22ev28.fsf@doganov.org>
References: <87ps22ev28.fsf@doganov.org>
Message-ID: <20070805170035.GB12184@nekral.homelinux.net>

Hello,


On Sun, Aug 05, 2007 at 02:31:11AM +0300, Kaloian Doganov wrote:
> Recently I've started to play with po4a while trying to
> internationalize a bunch of articles in HTML format.  One of the major
> obstacles for making the job done is this: po4a considers as
> translatable (almost) only the text contained between the tags of an
> element.  This is OK, but sometimes is not enough, since in HTML some
> attributes are intended to contain a human-readable text.  For
> example:
> 
>    <link rel="stylesheet" type="text/css" href="/new.css" title= "All-new style of mine">
> 
>    <a href="/" accesskey="1" title="Go to the project homepage">
> 
> The value of the `title' attribute here should be translatable too.
> 
> In fact, HTML.pm already does this by treating the IMG's `alt'
> attribute specially and thus making it's value translatable.  Maybe
> IMG's `alt' is the most common case for an attribute that needs
> translation, but there are three other elements that also can contain
> `alt': INPUT, AREA and APPLET.  They deserve the same treatment as
> IMG.
> 
> Also, it would be nice if `title' attribute is considered translatable
> too (keeping in mind that any element can contain a `title'
> attribute).
> 
> A patch that solves those two problems is attached.

Thanks a lot for your patch.

It is now applied in the po4a's repository.

Note also that you may want to try the xhtml module. It may provide a
better result (even if it's for regular HTML and not XHTML).

Best Regards,
-- 
Nekral


From debian.anti-spam at rutschle.net  Wed Aug  8 10:50:21 2007
From: debian.anti-spam at rutschle.net (Yves Rutschle)
Date: Wed, 8 Aug 2007 12:50:21 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070805170035.GB12184@nekral.homelinux.net>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
Message-ID: <20070808105021.GB28202@naryves.com>

> Note also that you may want to try the xhtml module. It may provide a
> better result (even if it's for regular HTML and not XHTML).

I second that. HTML.pm won't help much for any "big"
project, mostly because it doesn't manage in-line tags. This
means that things like:

<p>Independance day is on the 4<sup>th</sup> of July</p>

Turns into 3 msgids:

1: Independance day is on the 4
2: th
3: of July

This is awkward at best, but worse is that it won't help
translation in many languages.

Fixing HTML.pm turned out to be too complicated if you want
it to work on non-well-formed HTML. And if your HTML is
well-formed, you're almost up to using XHTML, which, on the
other hand, works pretty well (for me, anyway).

Y.


From yavor at gnu.org  Wed Aug  8 10:52:47 2007
From: yavor at gnu.org (Yavor Doganov)
Date: Wed, 8 Aug 2007 13:52:47 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808105021.GB28202@naryves.com>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
Message-ID: <20070808105246.GA19660@yavor.doganov.org>

On Wed, Aug 08, 2007 at 12:50:21PM +0200, Yves Rutschle wrote:
> > Note also that you may want to try the xhtml module. It may provide 
> > a better result (even if it's for regular HTML and not XHTML).
> 
> I second that. 

Unfortunately the XHTML backend is not suitable for us.  Our pages are 
XHTML, but they only become valid when the web server processes the 
various #include directives.

> <p>Independance day is on the 4<sup>th</sup> of July</p>
> 
> Turns into 3 msgids:
[...]
> This is awkward at best, but worse is that it won't help
> translation in many languages.

Yes, this violates the rule of thumb for i18n not to break sentences in 
this manner.  It becomes even worse if you have things <em>like</em> 
<i>this</i> where in some languages you have to insert a preposition or 
something else between them.

OTOH, Html.pm produces markup-free POT files, which is very good for our 
purpose: to separate the content entirely so the translator doesn't have 
to repeat the error-prone process of duplicating the markup.  But if it 
turns out that it is not possible to translate the content properly in 
some languages, this gain means nothing.

Sigh...


From debian.anti-spam at rutschle.net  Wed Aug  8 11:16:51 2007
From: debian.anti-spam at rutschle.net (Yves Rutschle)
Date: Wed, 8 Aug 2007 13:16:51 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808105246.GA19660@yavor.doganov.org>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
Message-ID: <20070808111651.GC28202@naryves.com>

On Wed, Aug 08, 2007 at 01:52:47PM +0300, Yavor Doganov wrote:
> Yes, this violates the rule of thumb for i18n not to break sentences in 
> this manner.  It becomes even worse if you have things <em>like</em> 
> <i>this</i> where in some languages you have to insert a preposition or 
> something else between them.

Oh, that reminds me of another problem: if somewhere else
you write that you <em>like</em> HTML, po4a helpfully
assumes 'like' in 'like this' and 'like' in 'I like it' are
the same. That rarely produces useful content in other
languages :-)

> OTOH, Html.pm produces markup-free POT files, which is very good for our 
> purpose: to separate the content entirely so the translator doesn't have 
> to repeat the error-prone process of duplicating the markup.  But if it 
> turns out that it is not possible to translate the content properly in 
> some languages, this gain means nothing.

I think you need to assess your exact  need: If the need is
to translate the Web pages as they are, then there is little
other choice but to have the translator handle the inline
markup (in my first example, only the translator can decide
to turn "the 4<sup>th</sup> of July" into "Le 4 juillet").

But it the need is to get the content translated as
cheaply/easily as possible, then probably the best would be
to extract all the content to text, translate that, and
generate pages from that. You'd obviously lose text markup,
links and so on, though.

Y.


From yavor at gnu.org  Wed Aug  8 11:46:25 2007
From: yavor at gnu.org (Yavor Doganov)
Date: Wed, 8 Aug 2007 14:46:25 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808111651.GC28202@naryves.com>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808111651.GC28202@naryves.com>
Message-ID: <20070808114625.GA19795@yavor.doganov.org>

On Wed, Aug 08, 2007 at 01:16:51PM +0200, Yves Rutschle wrote:
> On Wed, Aug 08, 2007 at 01:52:47PM +0300, Yavor Doganov wrote:
> > Yes, this violates the rule of thumb for i18n not to break 
> 
> Oh, that reminds me of another problem: if somewhere else you write 
> that you <em>like</em> HTML, po4a helpfully assumes 'like' in 'like 
> this' and 'like' in 'I like it' are the same. That rarely produces 
> useful content in other languages :-)

Argh :-(

> I think you need to assess your exact need: If the need is to 
> translate the Web pages as they are, then there is little other choice 
> but to have the translator handle the inline markup (in my first 
> example, only the translator can decide to turn "the 4<sup>th</sup> of 
> July" into "Le 4 juillet").

It's a judgement call: it has to be as easier as possible, but proper 
translation to literally any language on Earth is a must.  I guess in 
your above example we would just modify the original English page as a 
workaround.

The problem is that we don't have a choice, really: po4a with `-f xhtml' 
exits with an error (quite correctly) when operating on a file of ours, 
while `-f html' has this huge disadvantage...


From kaloian at doganov.org  Wed Aug  8 12:00:25 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Wed, 08 Aug 2007 15:00:25 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808105246.GA19660@yavor.doganov.org> (Yavor Doganov's
	message of "Wed\, 8 Aug 2007 13\:52\:47 +0300")
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
Message-ID: <87vebqqlra.fsf@doganov.org>

Yavor Doganov <yavor at gnu.org> writes:

    Unfortunately the XHTML backend is not suitable for us.  Our pages
    are XHTML, but they only become valid when the web server
    processes the various #include directives.

Strictly speaking, at the time being processed by po4a, our documents
in their source format are not even well-formed.  Yes, they happen to
be valid XHTML when served to the HTTP clients, but that's a lot later
? after SSI takes place.

So, any backend that requires a well-formed input is unusable for us.
If the problem with inline elements turns out to be a real trouble,
maybe we'll look how to improve po4a's HTML module to process inline
elements like XHTML does.
    

-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From po4a-bugs at alioth.debian.org  Wed Aug  8 12:08:50 2007
From: po4a-bugs at alioth.debian.org (po4a-bugs at alioth.debian.org)
Date: Wed, 08 Aug 2007 12:08:50 +0000
Subject: [Po4a-devel] =?utf-8?q?=5Bpo4a-Bugs=5D=5B304394=5D_Unexpected_esc?=
	=?utf-8?q?aped_chars_in_the_po?=
Message-ID: <E1IIkLK-0008Ve-G1@alioth.debian.org>

Bugs item #304394, was opened at 30/04/2007 14:24
Status: Open
Priority: 3
Submitted By: Nobody (None)
>Assigned to: Nicolas FRANCOIS  (nekral-guest)
Summary: Unexpected escaped chars in the po 
Category: None
Group: None
Resolution: None


Initial Comment:
Hi,
It seems that the "\n*" are replaced by "  *" (where * is not a wildcard).
The bug is visible in the removed 0.30 series, don't know for other release.

----------------------------------------------------------------------

>Comment By: Nicolas FRANCOIS  (nekral-guest)
Date: 08/08/2007 14:08

Message:
Hello,

Could you provide a test file, and indicate which module you used?

Thanks in advance

----------------------------------------------------------------------

You can respond by visiting: 
http://alioth.debian.org/tracker/?func=detail&atid=410622&aid=304394&group_id=30267


From nicolas.francois at centraliens.net  Wed Aug  8 12:16:01 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Wed, 8 Aug 2007 14:16:01 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808105246.GA19660@yavor.doganov.org>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
Message-ID: <20070808121601.GA19800@nekral.homelinux.net>

On Wed, Aug 08, 2007 at 01:52:47PM +0300, yavor at gnu.org wrote:
> On Wed, Aug 08, 2007 at 12:50:21PM +0200, Yves Rutschle wrote:
> > > Note also that you may want to try the xhtml module. It may provide 
> > > a better result (even if it's for regular HTML and not XHTML).
> > 
> > I second that. 
> 
> Unfortunately the XHTML backend is not suitable for us.  Our pages are 
> XHTML, but they only become valid when the web server processes the 
> various #include directives.

The Xml module (and hence the Xhtml module, which is based on it) does not
try to validate the page, so it may work anyway.

If it does not work, I can have a look at it (i.e. either implement
something like #include, or try to tweak the Xhtml module so that it works
on your pages).

IMO, if the #include thing does not do nasty things, like opening a tag in
one file and closing it in another, there should be no problem.

Regarding #include, I recently added support for external parsed entities
in Xml, which should be quite equivalent.

I will try to release 0.32 soon.

Best Regards,
-- 
Nekral


From yavor at gnu.org  Wed Aug  8 12:20:24 2007
From: yavor at gnu.org (Yavor Doganov)
Date: Wed, 8 Aug 2007 15:20:24 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808121601.GA19800@nekral.homelinux.net>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
Message-ID: <20070808122024.GA19933@yavor.doganov.org>

On Wed, Aug 08, 2007 at 02:16:01PM +0200, Nicolas Fran?ois wrote:
> IMO, if the #include thing does not do nasty things, like opening a 
> tag in one file and closing it in another, there should be no problem. 

It does nasty things; here's an example:
http://web.cvs.savannah.gnu.org/viewvc/www/philosophy/schools.html?revision=1.30&root=www&view=markup


From nicolas.francois at centraliens.net  Wed Aug  8 15:34:33 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Wed, 8 Aug 2007 17:34:33 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808122024.GA19933@yavor.doganov.org>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
Message-ID: <20070808153433.GB19800@nekral.homelinux.net>

Hello,

On Wed, Aug 08, 2007 at 03:20:24PM +0300, yavor at gnu.org wrote:
> On Wed, Aug 08, 2007 at 02:16:01PM +0200, Nicolas Fran?ois wrote:
> > IMO, if the #include thing does not do nasty things, like opening a 
> > tag in one file and closing it in another, there should be no problem. 
> 
> It does nasty things; here's an example:
> http://web.cvs.savannah.gnu.org/viewvc/www/philosophy/schools.html?revision=1.30&root=www&view=markup

Thanks for the pointer.

It seems it's a common feature (SSI), so I will consider implementing it
in the Xhtml module.

I can also add an option to support invalid Xml files (In this case, a div
section is closed but the parser do not see the opening tag since it is
in the included file).

Regarding file inclusion, here is how it works with the other po4a formats
which support file inclusion:
    When po4a parses the master file, it reads the other files when they
    are included and includes the file in the generated translation (i.e.
    the generated file will not have #include stanza).
Is it a problem? [0]

This may change the spirit of the translated header.html or banner.html
(e.g. header.bg.html), since they won't be used anymore (but the same
translation for every files may be enforced if they use the same PO file,
and the existing translation can be re-used quite easily using
po4a-gettextize).

Another option could be added to support reading the included file (to
build the tag tree), without really including it. (I currently don't see
the need for such an option, see also [0])

To use the current Xhtml module, you could move the opening <div>s from
the end of the banner to the beginning of school.html, and make a footer
which closes what the header opened.
(I understand that it may mean to change a lot files in this server)


[0] I don't think it is a problem. These #include are useful to avoid
rewriting always the same section and to enforce consistency between
pages. In the case of generated files, this is not a problem. The
documents will be a bit bigger, but we are just talking about a few
kilobytes.


Kind Regards,
-- 
Nekral


From nicolas.francois at centraliens.net  Wed Aug  8 15:38:08 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Wed, 8 Aug 2007 17:38:08 +0200
Subject: [Po4a-devel] Preparation of the next po4a 0.32 release
Message-ID: <20070808153808.GC19800@nekral.homelinux.net>

Hello,

I intend to release po4a next week (15th of August).

I don't expect a lot of string changes until then.
If you need more time to update the translations, just let me know. I can
change the date, or plan a dot-release afterwards.

If you want a feature or bug fix in 0.32, please raise your hand.

I will give a try to Server Side Includes for the Xhtml module. This will
probably introduce an option in the Xhtml module and another one in the
Xml module (and their documentation).


Here are the current status of the translations:
================================================

Translations of the binaries:
-----------------------------
af:    22t 11f 129u
ar:     1t     161u
ca:   145t  6f  11u
de:    51t 21f  90u
cs:    11t 15f 136u
eo:    24t  2f 136u
es:   145t  6f  11u
eu:    11t  2f 149u
fr:   162t
he:     3t  1f 158u
it:   135t 14f  13u
ku:     4t  1f 157u
nb:    51t 17f  94u
nl:    12t  2f 148u
pl:   157t  2f   3u
pt:    10t  2f 150u
ru:   145t  6f  11u
sl:     6t  8f 148u
sv:   132t  9f  21u
uk:     4t  6f 152u
pt_BR: 20t  6f 136u


You can find the PO files in:
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/po4a/po/bin/?cvsroot=po4a

Translations of the man pages:
------------------------------
ca:  842t 99f 192u
es:  842t 99f 192u
fr: 1103t       1u
it:  292t 91f 750u
pl: 1121t  6f   6u

You can find the PO files in:
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/po4a/po/pod/?cvsroot=po4a

The major changes for this release are:
=======================================
** Security fix
  Fix a possible race condition on a file created in /tmp.

** Bug fixes

  sgml: The handling of newlines was broken in no-wrap sections in 0.31

  xhtml: The module is now distributed as the other modules.

  texinfo: Fix infinite loop when a command parameter ends with \
           (as in @samp{\})

** New features

  xml: New option includeexternal to support external entities.

  texinfo: Added support for many commands and environment (see
           changelog).

Kind Regards,
-- 
Nekral


From nicolas.francois at centraliens.net  Wed Aug  8 21:22:26 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Wed, 8 Aug 2007 23:22:26 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808153433.GB19800@nekral.homelinux.net>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
Message-ID: <20070808212226.GD19800@nekral.homelinux.net>

Hello,

On Wed, Aug 08, 2007 at 05:34:33PM +0200, nicolas.francois at centraliens.net wrote:
> Hello,
> 
> On Wed, Aug 08, 2007 at 03:20:24PM +0300, yavor at gnu.org wrote:
> > On Wed, Aug 08, 2007 at 02:16:01PM +0200, Nicolas Fran?ois wrote:
> > > IMO, if the #include thing does not do nasty things, like opening a 
> > > tag in one file and closing it in another, there should be no problem. 
> > 
> > It does nasty things; here's an example:
> > http://web.cvs.savannah.gnu.org/viewvc/www/philosophy/schools.html?revision=1.30&root=www&view=markup
> 
> Thanks for the pointer.
> 
> It seems it's a common feature (SSI), so I will consider implementing it
> in the Xhtml module.

I've added an includessi option to the xhtml module. Here is the result.

The attached tar ball contains the resulting PO file and a resulting
translated document (well, translated ... in English).

Yavor or Kaloian, could you check if that seems correct/usable to you?

Kind Regards,
-- 
Nekral
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schools.tar.gz
Type: application/octet-stream
Size: 7547 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070808/6f012497/attachment-0001.obj 

From debian.anti-spam at rutschle.net  Thu Aug  9 07:58:44 2007
From: debian.anti-spam at rutschle.net (Yves Rutschle)
Date: Thu, 9 Aug 2007 09:58:44 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070808153433.GB19800@nekral.homelinux.net>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
Message-ID: <20070809075844.GD28202@naryves.com>

On Wed, Aug 08, 2007 at 05:34:33PM +0200, Nicolas Fran?ois wrote:
> It seems it's a common feature (SSI), so I will consider implementing it
> in the Xhtml module.

I know talk is cheap, but I don't have time to code this
myself, however I'd suggest doing differently and allowing
Xhtml.pm to call an external pre-filter program instead of
doing the SSI work directly in Xhtml.pm. This way if someone
was using the C preprocessor, or m4, or whatever to include
files the whole process still works.

In fact, it might make sense to have such an option at a
more generic level (Xml.pm, or even for every file?)

> To use the current Xhtml module, you could move the
> opening <divs from the end of the banner to the beginning
> of school.html, and make a footer which closes what the
> header opened.  (I understand that it may mean to change a
> lot files in this server)

This is what we went through when we moved to using
Xhtml.pm. The goal being that every file is individually
well-formed, and you only ever include entire sections. It
seems to work well in practice, and there are several
reasons it's a good idea: It's cleaner, it allows the Web
developers to work on proper XHTML, and it lets you use
automated tools (because this problem is not po4a-specific:
most every XML/Xhtml tool out there will choke on SSI or
non-well-formed code).

In the end, I'd say it was worth the pain, especially
considering that most of it can be automated with a good vi
macro.

Y.


From kaloian at doganov.org  Thu Aug  9 10:36:19 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Thu, 09 Aug 2007 13:36:19 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070809075844.GD28202@naryves.com> (Yves Rutschle's message of
	"Thu\, 9 Aug 2007 09\:58\:44 +0200")
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com>
Message-ID: <877io56llo.fsf@doganov.org>

Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:

    When po4a parses the master file, it reads the other files when
    they are included and includes the file in the generated
    translation (i.e.  the generated file will not have #include
    stanza).  Is it a problem?

Yes, it is a problem.  The new option `includessi' may be useful in
some cases, but it's not what we need.  We really don't want the
strings from other files to be included in the generated .pot-file.
The point of using those included files in the first place is:

 1. to separate the repeatable parts, so that the pages can become
    more manageable;

 2. to make the actual text of the articles independend of the
    navigational menus and other items around them; we don't want to
    update all translations of all articles on the site just because
    the webmaster adds a new item in the navigation menu.

So, we would like to keep included files like "www/server/banner.html"
separately and translate them separately from the articles that
includes them.

Yves Rutschle <debian.anti-spam at rutschle.net> writes:

    This is what we went through when we moved to using Xhtml.pm. The
    goal being that every file is individually well-formed, and you
    only ever include entire sections.

Sounds reasonable, but this way we cannot keep the simple paradigm:

    <!--#include virtual="/header.html" -->
    main text
    <!--#include virtual="/footer.html" -->

I'm not convinced it's worth breaking it.

I understand that it is reasonable for the xhtml module to expect a
well-formed input and I'm far from urging for changing this.  We're
still at an early prototype stage and we'll continue to experiment
before making any conclusions about 1) what should be changed on our
system and 2) how we want our tools to behave.


-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From nicolas.francois at centraliens.net  Thu Aug  9 11:45:42 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Thu, 9 Aug 2007 13:45:42 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070809075844.GD28202@naryves.com>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com>
Message-ID: <20070809114542.GA11327@nekral.homelinux.net>

On Thu, Aug 09, 2007 at 09:58:44AM +0200, debian.anti-spam at rutschle.net wrote:
> On Wed, Aug 08, 2007 at 05:34:33PM +0200, Nicolas Fran?ois wrote:
> > It seems it's a common feature (SSI), so I will consider implementing it
> > in the Xhtml module.
> 
> I know talk is cheap, but I don't have time to code this
> myself, however I'd suggest doing differently and allowing
> Xhtml.pm to call an external pre-filter program instead of
> doing the SSI work directly in Xhtml.pm. This way if someone
> was using the C preprocessor, or m4, or whatever to include
> files the whole process still works.
> 
> In fact, it might make sense to have such an option at a
> more generic level (Xml.pm, or even for every file?)

The Xhtml module only contained a configuration with a set of tags.

To implement SSI, I just needed to add an option and divert the f_extract
method of tag !--# to a specific extraction function. So it was clean
enough for me.

Providing support for filters (for any module) is a good idea.
I will add it to my TODO list for 0.33.

It may just be a matter of changing the Transtractor's read() to support
reading from "filter < file |" or "filter file |"

Best Regards,
-- 
Nekral


From nicolas.francois at centraliens.net  Thu Aug  9 12:16:53 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Thu, 9 Aug 2007 14:16:53 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <877io56llo.fsf@doganov.org>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
Message-ID: <20070809121653.GB11327@nekral.homelinux.net>

On Thu, Aug 09, 2007 at 01:36:19PM +0300, kaloian at doganov.org wrote:
> Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:
> 
>     When po4a parses the master file, it reads the other files when
>     they are included and includes the file in the generated
>     translation (i.e.  the generated file will not have #include
>     stanza).  Is it a problem?
> 
> Yes, it is a problem.  The new option `includessi' may be useful in
> some cases, but it's not what we need.  We really don't want the
> strings from other files to be included in the generated .pot-file.
> The point of using those included files in the first place is:
> 
>  1. to separate the repeatable parts, so that the pages can become
>     more manageable;

I don't think it's a problem.
Even if, with includessi, the file is included multiple times, the POT
file will contain only one copy of the common strings. So the work of
translating the included files will be done only once.

>  2. to make the actual text of the articles independend of the
>     navigational menus and other items around them; we don't want to
>     update all translations of all articles on the site just because
>     the webmaster adds a new item in the navigation menu.

This will just require to regenerate all the translated materials every
time one included file is changed.
But this will be automated by a script.

> So, we would like to keep included files like "www/server/banner.html"
> separately and translate them separately from the articles that
> includes them.

Could you test changing the "die" to a "warn" in tag_trans_close of the
Xml module (maybe also in treat_content).
This may be sufficient, and the resulting POT should be better than with
the Html module.

BTW, in that case should the SSI element be translatable?
Maybe
        <!--#include virtual="file.html" -->
Should be translated to
        <!--#include virtual="file.$lang.html" -->

I'm a bit reluctant currently to make the die => warn change (even with an
option), because I don't know how to react in the module.
I can think of 2 different strategies:
 * keep the tag tree
 * reset the tag tree
(* invoke voodoo magic to guess where we can branch in the tag tree)

> Yves Rutschle <debian.anti-spam at rutschle.net> writes:
> 
>     This is what we went through when we moved to using Xhtml.pm. The
>     goal being that every file is individually well-formed, and you
>     only ever include entire sections.
> 
> Sounds reasonable, but this way we cannot keep the simple paradigm:
> 
>     <!--#include virtual="/header.html" -->
>     main text
>     <!--#include virtual="/footer.html" -->

I don't think in that case the header and footer documents can be well
formed, but it would be better if the footer was closing the tags opened
by the header (that way, the main document can be parsed).

In any case, the header will contain open tags which are not closed (it
should be OK for the Xhtml module). And the footer will contain closing
tags for tags not opened (which the Xhtml module does not support).

The latter could be solved by indicating to the module that it shall start
with a given tag tree. (Or by using a non translatable footer)

And by the way, we could also support some special comments in the middle
of a document, like:
     <!-- po4a: </head><body><div> -->
(which would indicate to po4a that it shall close the current "head" tag and
open a "body" and "div" tag)

If anything makes sense here, just tell me.

Cheers,
-- 
Nekral


From kaloian at doganov.org  Thu Aug  9 18:01:47 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Thu, 09 Aug 2007 21:01:47 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070809121653.GB11327@nekral.homelinux.net> ("Nicolas
	=?utf-8?Q?Fran=C3=A7ois=22's?= message of "Thu\, 9 Aug 2007 14\:16\:53
	+0200")
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
	<20070809121653.GB11327@nekral.homelinux.net>
Message-ID: <873ays7fjo.fsf@doganov.org>

Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:

    I don't think it's a problem.  Even if, with includessi, the file
    is included multiple times, the POT file will contain only one
    copy of the common strings. So the work of translating the
    included files will be done only once.

I agree that there is no problem when including one external file
multiple times in an article.  (We don't have such case, I think.).
The problem is when there are hundreth of articles that all include a
few common external files.  (Which is more like our case.)  We would
like to translate the few common external files separately from the
articles they are included in.
    
    This will just require to regenerate all the translated materials
    every time one included file is changed.  But this will be
    automated by a script.

Yes, it can be automated, but it is undesired anyway, because a small
change in an included file can easily lead to changes in a hundreth of
files.  In the long run, tracing all those changes will be a very
heavy burden for the webmasters.  We would like to avoid it, if we
can.
    
    Could you test changing the "die" to a "warn" in tag_trans_close
    of the Xml module (maybe also in treat_content).  This may be
    sufficient, and the resulting POT should be better than with the
    Html module.

A quick test shows that changing just `tag_trans_close' does the job.

(It is hard to test this in the current CVS HEAD, because for some
reason po4a always resolves SSI #include directives.  So, I did it in
a slightly older version of CVS HEAD, which still does not support
`includessi'.)
    
    BTW, in that case should the SSI element be translatable?
    Maybe
            <!--#include virtual="file.html" -->
    Should be translated to
            <!--#include virtual="file.$lang.html" -->

We're doing this with a simple sed script, there is no need to bother
the translators (or po4a) with this.
    
    I'm a bit reluctant currently to make the die => warn change (even
    with an option), because I don't know how to react in the module.
    I can think of 2 different strategies:

     * keep the tag tree
     * reset the tag tree
    (* invoke voodoo magic to guess where we can branch in the tag
    tree)

If I understand correctly, the question is what to do with the tag
tree when an unexpected closing tag is encountered by the parser.  In
this case, we can assume that the corresponding matching tag is opened
in another file which we don't see for some reason (#include).  With
this assumption, the right thing to do is to reset the tag tree.

    In any case, the header will contain open tags which are not
    closed (it should be OK for the Xhtml module). And the footer will
    contain closing tags for tags not opened (which the Xhtml module
    does not support).
    
    The latter could be solved by indicating to the module that it
    shall start with a given tag tree. (Or by using a non translatable
    footer)
    
    And by the way, we could also support some special comments in the
    middle of a document, like:
         <!-- po4a: </head><body><div> -->
    (which would indicate to po4a that it shall close the current
    "head" tag and open a "body" and "div" tag)

I don't think there is a good reason to bother with keeping track of
the tag tree between separate files and introducing special comments
like the example above.  It looks like adding an option for changing
"die" to "warn" (just for block elements) is enough.
    

-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From debian.anti-spam at rutschle.net  Thu Aug  9 20:22:53 2007
From: debian.anti-spam at rutschle.net (Yves Rutschle)
Date: Thu, 9 Aug 2007 22:22:53 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <877io56llo.fsf@doganov.org>
References: <87ps22ev28.fsf@doganov.org>
	<20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
Message-ID: <20070809202253.GE28202@naryves.com>

On Thu, Aug 09, 2007 at 01:36:19PM +0300, Kaloian Doganov wrote:
>     This is what we went through when we moved to using Xhtml.pm. The
>     goal being that every file is individually well-formed, and you
>     only ever include entire sections.
> 
> Sounds reasonable, but this way we cannot keep the simple paradigm:
> 
>     <!--#include virtual="/header.html" -->
>     main text
>     <!--#include virtual="/footer.html" -->
> 
> I'm not convinced it's worth breaking it.

What we have is a skeleton, so a file looks like:

<html>
<!--#include virtual="header.html"-->

<body>
  main text
</body>
<!--#include virtual="footer.html"-->
</html>

I guess that is more cruft than your solution.
 
> I understand that it is reasonable for the xhtml module to expect a
> well-formed input and I'm far from urging for changing this.

Well, if it can be made to work on other inputs, it'd be a
shame not to do that. At the end of the day, a good tool is
a tool that does something useful :)

Y.


From nicolas.francois at centraliens.net  Thu Aug  9 21:36:39 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Thu, 9 Aug 2007 23:36:39 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <873ays7fjo.fsf@doganov.org>
References: <20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
	<20070809121653.GB11327@nekral.homelinux.net>
	<873ays7fjo.fsf@doganov.org>
Message-ID: <20070809213639.GB10543@nekral.homelinux.net>

Hi,

On Thu, Aug 09, 2007 at 09:01:47PM +0300, kaloian at doganov.org wrote:
> Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:
> 
>     I don't think it's a problem.  Even if, with includessi, the file
>     is included multiple times, the POT file will contain only one
>     copy of the common strings. So the work of translating the
>     included files will be done only once.
> 
> I agree that there is no problem when including one external file
> multiple times in an article.  (We don't have such case, I think.).
> The problem is when there are hundreth of articles that all include a
> few common external files.  (Which is more like our case.)  We would
> like to translate the few common external files separately from the
> articles they are included in.

I would use a single POT for all the files.

> A quick test shows that changing just `tag_trans_close' does the job.

Nice.

See attached a patch I plan to commit.

It adds a ontagerror option to the Xml module, and implement multiple
strategies.
In your case, I wonder if a "silent" strategy could not be useful.

> (It is hard to test this in the current CVS HEAD, because for some
> reason po4a always resolves SSI #include directives.  So, I did it in
> a slightly older version of CVS HEAD, which still does not support
> `includessi'.)

Thanks for noticing. That's fixed.

>     BTW, in that case should the SSI element be translatable?
>     Maybe
>             <!--#include virtual="file.html" -->
>     Should be translated to
>             <!--#include virtual="file.$lang.html" -->
> 
> We're doing this with a simple sed script, there is no need to bother
> the translators (or po4a) with this.

Well, if it's useful for many peoples, it's worth it.

Kind Regards,
-- 
Nekral
-------------- next part --------------
A non-text attachment was scrubbed...
Name: po4a_Xml_ontagerror.patch
Type: text/x-diff
Size: 5034 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070809/f124517a/attachment.patch 

From kaloian at doganov.org  Sat Aug 11 21:51:47 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 12 Aug 2007 00:51:47 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <20070809213639.GB10543@nekral.homelinux.net> ("Nicolas
	=?utf-8?Q?Fran=C3=A7ois=22's?= message of "Thu\, 9 Aug 2007 23\:36\:39
	+0200")
References: <20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
	<20070809121653.GB11327@nekral.homelinux.net>
	<873ays7fjo.fsf@doganov.org>
	<20070809213639.GB10543@nekral.homelinux.net>
Message-ID: <87lkch3fkc.fsf@doganov.org>

Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:

    I would use a single POT for all the files.

This will lead to an unmaintainable mess.  Usually, different articles
are translated and maintained by different persons.  Working with all
the strings of all articles together in a single po-file will be a
nightmare for translators.
    
    See attached a patch I plan to commit.  It adds a ontagerror
    option to the Xml module, and implement multiple strategies.

Great!  Using this patch and "ontagerror=reset" option makes po4a
almost perfect for the job.

I've noticed a problem with the output of po4a-translate.  An empty
elements with no tag names appear where the non-matching closing tags
should be found.  Here is an example:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070812/47c09801/attachment.html 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070812/47c09801/attachment-0001.html 

From kaloian at doganov.org  Sun Aug 12 01:22:29 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 12 Aug 2007 04:22:29 +0300
Subject: [Po4a-devel] Xhtml module: Integrated comments and strange
	whitespace
Message-ID: <87hcn535t6.fsf@doganov.org>

An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070812/ef23422e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: po4a-normalize.output.xhtml
Type: application/xhtml+xml
Size: 880 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070812/ef23422e/attachment.xhtml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: po4a-normalize.output.2.xhtml
Type: application/xhtml+xml
Size: 875 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070812/ef23422e/attachment-0001.xhtml 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070812/ef23422e/attachment-0001.html 

From kaloian at doganov.org  Sun Aug 12 12:31:30 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 12 Aug 2007 15:31:30 +0300
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <87lkch3fkc.fsf@doganov.org> (Kaloian Doganov's message of "Sun\,
	12 Aug 2007 00\:51\:47 +0300")
References: <20070805170035.GB12184@nekral.homelinux.net>
	<20070808105021.GB28202@naryves.com>
	<20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
	<20070809121653.GB11327@nekral.homelinux.net>
	<873ays7fjo.fsf@doganov.org>
	<20070809213639.GB10543@nekral.homelinux.net>
	<87lkch3fkc.fsf@doganov.org>
Message-ID: <874pj52au5.fsf@doganov.org>

    I've noticed a problem with the output of po4a-translate.  An
    empty elements with no tag names appear where the non-matching
    closing tags should be found.

This bug cannot be reproduced using pristine po4a from the current CVS
HEAD and `-o ontagerror=silent'.


-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From nicolas.francois at centraliens.net  Sun Aug 12 12:44:36 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Sun, 12 Aug 2007 14:44:36 +0200
Subject: [Po4a-devel] Translatable attributes in HTML
In-Reply-To: <87lkch3fkc.fsf@doganov.org>
References: <20070808105246.GA19660@yavor.doganov.org>
	<20070808121601.GA19800@nekral.homelinux.net>
	<20070808122024.GA19933@yavor.doganov.org>
	<20070808153433.GB19800@nekral.homelinux.net>
	<20070809075844.GD28202@naryves.com> <877io56llo.fsf@doganov.org>
	<20070809121653.GB11327@nekral.homelinux.net>
	<873ays7fjo.fsf@doganov.org>
	<20070809213639.GB10543@nekral.homelinux.net>
	<87lkch3fkc.fsf@doganov.org>
Message-ID: <20070812124436.GA7495@nekral.homelinux.net>

Hello,

On Sun, Aug 12, 2007 at 12:51:47AM +0300, kaloian at doganov.org wrote:
> Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:
> 
>     See attached a patch I plan to commit.  It adds a ontagerror
>     option to the Xml module, and implement multiple strategies.
> 
> Great!  Using this patch and "ontagerror=reset" option makes po4a
> almost perfect for the job.

Thanks a lot for testing.

> I've noticed a problem with the output of po4a-translate.  An empty
> elements with no tag names appear where the non-matching closing tags
> should be found.  Here is an example:

I fixed it (@tag was reset instead of @path).

I committed the patch, but I changed the available parameters.

ontagerror now supports 3 parameters: fail, warn and silent.

"fail" is still the default.
Use "warn" if the input Xml file is invalid (and you can't fix the input).
Use "silent" if the input is valid but considered as invalid by po4a.

(So in your case, "silent" is probably the preferred parameter)

Cheers,
-- 
Nekral


From nicolas.francois at centraliens.net  Sun Aug 12 13:43:43 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Sun, 12 Aug 2007 15:43:43 +0200
Subject: [Po4a-devel] Xhtml module: Integrated comments and
	strange	whitespace
In-Reply-To: <87hcn535t6.fsf@doganov.org>
References: <87hcn535t6.fsf@doganov.org>
Message-ID: <20070812134343.GB7495@nekral.homelinux.net>

Hi,

On Sun, Aug 12, 2007 at 04:22:29AM +0300, kaloian at doganov.org wrote:
> There is another problem with po4a-translate and Xhtml module that
> I've run into.
> 
> If the input document contains a group of adjacent comments, those
> adjacent comments became integrated as one big comment, preceded by
> newlines.  The number of preceding newlines is equal to the number of
> lines used by the group of comments.

Comments in a paragraph are grouped to be presented in the PO (it is
sometimes useful to see the comments in the PO).

Just an explanation why there are some empty lines and only one comment.

in
        <!-- foo -->
        <!-- bar -->
there are newline and spaces between the two comments.

The comments are extracted, and the newline and spaces are added to the
current paragraph (to be translated).

At the end of the paragraph, the cumulated text are presented in the PO
(with the cumulated comments).

Newlines and spaces at the beginning of the paragraph are extracted (i.e.
not translated), and printed in the output text.

In the example, as there are no translatable text, the comments are just
printed in the output text (without being present in the PO).



I understand that the empty lines and the concatenation of comments is not
very pretty (this can be even more strange when there are comments before,
in the middle and after a translatable paragraph), but is it really an
issue?


> Appart from the problem described, here we can see how the last
> comment of the group has survived the integration.  It looks like it
> is saved by the fact that there is no whitespace between the starting
> sequence "<!--" and the actual text of the comment ("#include...").
> If I put a single space between them, po4a-normalize integrates this
> comment alongside with the others:

Comments introduced by <!--# are recognized as SSI stanza and are
extracted differently. (This support for SSI existed before the
introduction of the includessi option)

Best Regards,
-- 
Nekral


From kaloian at doganov.org  Sun Aug 12 16:00:45 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 12 Aug 2007 19:00:45 +0300
Subject: [Po4a-devel] Xhtml module: Integrated comments and
	strange	whitespace
In-Reply-To: <20070812134343.GB7495@nekral.homelinux.net> ("Nicolas
	=?utf-8?Q?Fran=C3=A7ois=22's?= message of "Sun\, 12 Aug 2007 15\:43\:43
	+0200")
References: <87hcn535t6.fsf@doganov.org>
	<20070812134343.GB7495@nekral.homelinux.net>
Message-ID: <87eji8zqs2.fsf@doganov.org>

Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:

    I understand that the empty lines and the concatenation of
    comments is not very pretty (this can be even more strange when
    there are comments before, in the middle and after a translatable
    paragraph), but is it really an issue?

It's nice not to have a screen of empty lines in the resulting
document, but it's not fatal to have them.  They can't cause a
misintepretation of the document and that's the most important.  Even
if we still don't like them for some reason, we can always strip them
with an external script afterwards.

But the concatenation of comments is a real issue.  It is useful to
have a construct that is guaranteed not to be modified by the
processing tool (po4a).  In Html module, comments were such
constructs.  We used them in a preprocessing phase to leave marks and
placeholders in the original document that have special meaning to our
postprocessing tools.  The workflow is (very roughly):

   Process an article
   ------------------
   1. Preprocess the original article
   2. Run po4a on the preprocessed article to get localized one
   3. Postprocess the localized article

For instance, in the first phase we comment out some portions of the
document that must not be made translatable.  Here is one real
example:

    <p>
    Updated:
    <!-- timestamp start -->
    $Date: 2007/06/19 00:02:58 $
    <!-- timestamp end -->
    </p>

We don't want the line with $Date to be translatable at all, since it
is set automatically by CVS.  This is a dynamically changing string
that we don't want to leak in POT and POs.  So we comment it out and
after the preprocessing phase the fragment looks like this:

    <p>
    Updated:
    <!-- timestamp start -->
    <!-- $Date: 2007/06/19 00:02:58 $ -->
    <!-- timestamp end -->
    </p>

After the po4a phase it looks like (for Bulgarian):

    <p>
    ???????? ??????????:
    <!-- timestamp start -->
    <!-- $Date: 2007/06/19 00:02:58 $ -->
    <!-- timestamp end -->
    </p>

And finally, after the postprocessing phase the fragment looks like
this (for Bulgarian):

    <p>
    ???????? ??????????:
    <!-- timestamp start -->
    $Date: 2007/06/19 00:02:58 $
    <!-- timestamp end -->
    </p>

This was working fine with Html module, but Xhtml's comment
concatenation breaks it.  I don't insist on keeping the Html's way of
doing things, I can imagine that comment concatenation may be good in
other cases, but it is really useful to have some construct that po4a
will just pass verbatim into the output document.

(The above example was picked because is the shortest one.)


-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From nicolas.francois at centraliens.net  Sun Aug 12 16:43:10 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Sun, 12 Aug 2007 18:43:10 +0200
Subject: [Po4a-devel] Xhtml module: Integrated comments and
	strange	whitespace
In-Reply-To: <87eji8zqs2.fsf@doganov.org>
References: <87hcn535t6.fsf@doganov.org>
	<20070812134343.GB7495@nekral.homelinux.net>
	<87eji8zqs2.fsf@doganov.org>
Message-ID: <20070812164310.GC7495@nekral.homelinux.net>

On Sun, Aug 12, 2007 at 07:00:45PM +0300, kaloian at doganov.org wrote:
> Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:
> 
> But the concatenation of comments is a real issue.  It is useful to
> have a construct that is guaranteed not to be modified by the
> processing tool (po4a).  In Html module, comments were such
> constructs.  We used them in a preprocessing phase to leave marks and
> placeholders in the original document that have special meaning to our
> postprocessing tools.  The workflow is (very roughly):
> 
>    Process an article
>    ------------------
>    1. Preprocess the original article
>    2. Run po4a on the preprocessed article to get localized one
>    3. Postprocess the localized article
> 
> For instance, in the first phase we comment out some portions of the
> document that must not be made translatable.  Here is one real
> example:
[...]
>     <p>
>     Updated:
>     <!-- timestamp start -->
>     <!-- $Date: 2007/06/19 00:02:58 $ -->
>     <!-- timestamp end -->
>     </p>

OK. I see how you use it.

One option could be to use another trick:
        <p>
        Updated:
        <timestamp date="$Date: 2007/06/19 00:02:58 $">
        </p>

This could be generated by the preprocessor, and the timestamp could be
restored afterward by the postprocessor.

I can try to add an option to handle comments differently:
 * drop comments inside a line
   (foo bar<!-- comment> baz qux)
 * keep the comments for lines which only contain comments (and spaces)
 * Use this commented lines as paragraph separators.
 * keep the comments gathered since the last paragraph to display them in
   the PO (but print them as is in the generated document)

(If we want to output the comments in place where they were found,
paragraphs like:

        foo bar
        <!-- comment -->
        baz qux

will have to be translated as two different paragraphs.)

I will work on it after the 0.32 release.

Best Regards,
-- 
Nekral


From nicolas.francois at centraliens.net  Fri Aug 17 11:32:39 2007
From: nicolas.francois at centraliens.net (Nicolas =?iso-8859-1?Q?Fran=E7ois?=)
Date: Fri, 17 Aug 2007 13:32:39 +0200
Subject: [Po4a-devel] Preparation of the next po4a 0.32 release
In-Reply-To: <20070808153808.GC19800@nekral.homelinux.net>
References: <20070808153808.GC19800@nekral.homelinux.net>
Message-ID: <20070817113238.GB7446@nekral.homelinux.net>

Hello,

po4a 0.32 was released.

I will prepare the Debian package, but it will probably be uploaded only
next week.

BTW, I've updated the po4a web site, based on the proposal prepared by
Jordi a few years ago:

http://po4a.alioth.debian.org/

Best Regards,
-- 
Nekral


From kaloian at doganov.org  Sun Aug 12 20:31:54 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 12 Aug 2007 23:31:54 +0300
Subject: [Po4a-devel] Xhtml module: Integrated comments and
	strange	whitespace
In-Reply-To: <20070812164310.GC7495@nekral.homelinux.net> ("Nicolas
	\=\?utf-8\?Q\?Fran\=C3\=A7ois\=22's\?\= message of "Sun\,
	12 Aug 2007 18\:43\:10 +0200")
References: <87hcn535t6.fsf@doganov.org>
	<20070812134343.GB7495@nekral.homelinux.net>
	<87eji8zqs2.fsf@doganov.org>
	<20070812164310.GC7495@nekral.homelinux.net>
Message-ID: <87643kze85.fsf@doganov.org>

Nicolas Fran?ois <nicolas.francois at centraliens.net> writes:
    
    One option could be to use another trick:
            <p>
            Updated:
            <timestamp date="$Date: 2007/06/19 00:02:58 $">
            </p>
    
    This could be generated by the preprocessor, and the timestamp could be
    restored afterward by the postprocessor.

Oh, looks like a viable option.  Thanks for the idea!  I'll try it out
as soon as I can.
    
    I can try to add an option to handle comments differently.  I will
    work on it after the 0.32 release.

Such an option would be very useful improvement.  Of course, there is
no rush.  Wish you good luck with the incoming release and thank you
for your invaluable help!
    

-- 
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm


From kaloian at doganov.org  Sun Aug 19 10:07:10 2007
From: kaloian at doganov.org (Kaloian Doganov)
Date: Sun, 19 Aug 2007 13:07:10 +0300
Subject: [Po4a-devel] Incorrect URL for sources download
Message-ID: <87lkc796sx.fsf@doganov.org>

A non-text attachment was scrubbed...
Name: sources-download.patch
Type: text/x-patch
Size: 472 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/po4a-devel/attachments/20070819/bad01414/attachment.bin