[Po4a-devel] Translatable attributes in HTML

Thu Aug 9 12:16:53 UTC 2007

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