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^th 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.

On Wed, Aug 08, 2007 at 01:52:47PM +0300, Yavor Doganov wrote: 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 :-) 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^th 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.

Yavor Doganov <yavor(a)gnu.org&gt; 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

On Wed, Aug 08, 2007 at 02:16:01PM +0200, Nicolas Franзois wrote: It does nasty things; here's an example: http://web.cvs.savannah.gnu.org/viewvc/www/philosophy/schools.html?revisi...

Hello, On Wed, Aug 08, 2007 at 05:34:33PM +0200, nicolas.francois(a)centraliens.net wrote: 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

Nicolas François <nicolas.francois(a)centraliens.net&gt; 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(a)rutschle.net&gt; 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

Nicolas François <nicolas.francois(a)centraliens.net&gt; 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

Nicolas François <nicolas.francois(a)centraliens.net&gt; 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: When processed with the following commands: $ po4a-gettextize --format xhtml -o ontagerror=reset \ --master test-case.html --po test-case.pot $ cp test-case.pot test-case.bg.po $ po4a-translate --format xhtml -o ontagerror=reset --keep 0 \ --master test-case.html --po test-case.bg.po \ --localized test-case.bg.html The resulted test-case.bg.html looks like this: As you can see, the output isn't identical to the input. The last two closing tags are missing, replaced by strange tags without names: 10,11c10,11 < </body> < </html> ---

Hello, On Sun, Aug 12, 2007 at 12:51:47AM +0300, kaloian(a)doganov.org wrote: Thanks a lot for testing. 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

On Thu, Aug 09, 2007 at 09:58:44AM +0200, debian.anti-spam(a)rutschle.net wrote: 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