On Thu, Aug 09, 2007 at 01:36:19PM +0300, kaloian(a)doganov.org wrote:
Nicolas François <nicolas.francois(a)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
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
separately and translate them separately from the articles that
Could you test changing the "die" to a "warn" in tag_trans_close of
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?
<!--#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(a)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" -->
<!--#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.