Re: [Po4a-devel] Translatable attributes in HTML
Nicolas François <nicolas.francois(a)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