Hello, On Sun, Aug 05, 2007 at 02:31:11AM +0300, Kaloian Doganov wrote: 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

On Wed, Aug 08, 2007 at 12:50:21PM +0200, Yves Rutschle wrote: 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. [...] 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...

On Wed, Aug 08, 2007 at 01:16:51PM +0200, Yves Rutschle wrote: Argh :-( 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...

On Wed, Aug 08, 2007 at 01:52:47PM +0300, yavor(a)gnu.org wrote: 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

Hello, On Wed, Aug 08, 2007 at 03:20:24PM +0300, yavor(a)gnu.org wrote: 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

On Wed, Aug 08, 2007 at 05:34:33PM +0200, Nicolas François wrote: 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?) 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.

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

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

Hi, On Thu, Aug 09, 2007 at 09:01:47PM +0300, kaloian(a)doganov.org wrote: I would use a single POT for all the files. 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. Thanks for noticing. That's fixed. Well, if it's useful for many peoples, it's worth it. Kind Regards, -- Nekral

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