Re: [Libreoffice] [GSOC] Report #5. Wizards
Wow, thank Peter for this amazing explanation. I'm currently sumerged into the gsoc project too so I can't give it a try right now but I'm sure I will once I finish it. The problem right now is I don't know most of the things you're talking about so I'll need first to get my feet wet. I'll let you know when I start to work on it. Greetings 2011/7/7 Peter Jentsch pj...@guineapics.de Hi Xisco, one more thing: I looked at at XSLTFilter code again and noticed that although a lot of data get's passed in to the import call, only a tiny fragment of that makes it to the actual transformation, so you won't be able to use any parameters in the transformation. I don't like that situation, and if you'd chose to investigate deeper into the approach I sketched out I'd extend the XSLT Filter call to pass parameters to the transformation. We get a MediaDescriptor struct handed in there, which has a string field FilterOptions that can be passed unmodified to any transformation. That should be sufficient if the total amount of information to get into the transformation remains small. Cheers, Peter Am 04.07.11 12:42, schrieb Michael Meeks: Hi Xisco, Peter - Xisco is working on re-writing the wizards in Java :-) On Fri, 2011-07-01 at 16:05 +0200, Xisco Faulí wrote: Michael wrote: Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) Xisco wrote: Yes, you're right but if I have some time before gsoc finishes (or even after) I'd like to take a look to it. Who should I get in contact with in order to get my feet wet ? Ah - so the XSLT expert is Peter Jentsch who has done a load of great work in this area, writing the much faster / smaller native C++ filter etc. He can prolly help out with some code pointers, and/or perhaps some simple example XSLTs that might be useful for translating attributes / elements (?), and ways to get feed the required data to them elegantly. HTH, Michael. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Peter, sorry for randomly jumping in with just some side-notes ... Am 06.07.2011 22:10, schrieb Peter Jentsch: I'm unsure about where to put the xliff files, because I'm completely ignorant of the translation workflow and the different places where translatable items are put in order to get easily picked up by translators. If we want to go that way, Andras Timar might have an idea about where to store this stuff. Plus, I found xliff allows for a lot of things, and the Xslt script will make a few assumptions on how (simple) the xliff file is structured, so the process might break easily if the translation tools want to do nasty things with the xliff file (that a fully working xliff toolchain would be required to understand). But maybe that's not happening anyway, and in practice it's less complex than it looks on first sight. Afaik there is hardly any fully working FOSS-based xliff toolchain that includes translation editors and complext xliff files. Translate toolkit has a quite good support for XLIFF - po conversion (as long as you do not use advanced xliff features). If we want to go that way, I could test the conversion and how this works for a translator. regards, André ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Xisco, one more thing: I looked at at XSLTFilter code again and noticed that although a lot of data get's passed in to the import call, only a tiny fragment of that makes it to the actual transformation, so you won't be able to use any parameters in the transformation. I don't like that situation, and if you'd chose to investigate deeper into the approach I sketched out I'd extend the XSLT Filter call to pass parameters to the transformation. We get a MediaDescriptor struct handed in there, which has a string field FilterOptions that can be passed unmodified to any transformation. That should be sufficient if the total amount of information to get into the transformation remains small. Cheers, Peter Am 04.07.11 12:42, schrieb Michael Meeks: Hi Xisco, Peter - Xisco is working on re-writing the wizards in Java :-) On Fri, 2011-07-01 at 16:05 +0200, Xisco Faulí wrote: Michael wrote: Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) Xisco wrote: Yes, you're right but if I have some time before gsoc finishes (or even after) I'd like to take a look to it. Who should I get in contact with in order to get my feet wet ? Ah - so the XSLT expert is Peter Jentsch who has done a load of great work in this area, writing the much faster / smaller native C++ filter etc. He can prolly help out with some code pointers, and/or perhaps some simple example XSLTs that might be useful for translating attributes / elements (?), and ways to get feed the required data to them elegantly. HTH, Michael. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Xisco, Michael, I had a look at how it'd be possible to translate the templates on the fly a couple of weeks ago. The basic approach I though of would be to use the XSLT filter for importing. On import, you'd try to load the document and pass a parameter that points to an XLIFF file that contains the translation strings. You'd then use the document() function in the xslt script to load the XLIFF file, have the XSLT template rules match the translatable items and then construct an xpath expression that pulls the translation from the node-set you got from loading the XLIFF file. While this might be pretty straighforward, by then I saw two problems: 1. How do we ensure the translatable templates remain maintainable 2. How do we integrate the translations into the common translation process for the rest of LO. It would be quite simple to mark translatable items, which range from simple span contents in the simplest wizard templates to translatable style names in the report wizards, directly in the XML files using some XML attributes we just invent for that purpose. By the time I though about it, I assumed that to be a big problem, because it might imply that the template content is not editable using LO, but only directly with a text-editor or xml editor. This might be much less of a problem given the fact that the templates, at least as they are now, shouldn't change that often. I will become a problem if we want to make the templates themselves configurable by end users, but that would imply a lot of other changes, so I think we can ignore that for now. So, looking at it from now, I'd just mark the translatable elements with xml id attributes that follow a naming convention. This would allow us to keep the XPath expression that identifies translatable elements very simple so then ... we can parse it and make a dynamic lookup from within the XSLT template that does the translation. so we end up with [...] xsl:param name=xliff-url/ xsl:param name=locale/ xsl:variable name=translations select=document($xliff-url))/ [...] xsl:template match=*[starts-with(@id, 'wizard.message.')] !-- matches any element that has an id attribute the content of which start with 'wizard.message' -- xsl:variable name=trans-id select=@id/ xsl:copy xsl:apply-templates select=@*/ xsl:value-of select=$translations//trans-unit[@id=$trans-id]/target[@xml:lang=$locale]/ /xsl:copy /xsl:template this won't work for translatable content with formatting. XLIFF provides for means to deal with that, but I don't understand them fully. I can't tell you now how exactly to pass the parameters xliff-url and locale to the xslt script, I don't even know for sure if thats possible in the current xslt filter framework. I could look at that if it proves to be non-trivial. you could come up with a different approach on how to identify translatable elements, for example by adding an attribute which is just only used for that, not the id attribute. That would have the benefit that you can have the same translatable string in a single document more than once. I'm unsure about where to put the xliff files, because I'm completely ignorant of the translation workflow and the different places where translatable items are put in order to get easily picked up by translators. Plus, I found xliff allows for a lot of things, and the Xslt script will make a few assumptions on how (simple) the xliff file is structured, so the process might break easily if the translation tools want to do nasty things with the xliff file (that a fully working xliff toolchain would be required to understand). But maybe that's not happening anyway, and in practice it's less complex than it looks on first sight. It'd be great if you'd be able to pick that one up, I'm currently deeply submerged into a lot of things unrelated to LO and unable to do any work on LO. Getting rid of all the translated template copies not only would recude installed size IMO, but also would ensure a more predictable result when working with the templates in different languages. I've noticed, when looking at the templates, that most are constructed equal, but no necessarily all, but for reasons that didn't seem to relate to locale specific requirements. Looking forward to hearing from you, Peter Am 04.07.11 12:42, schrieb Michael Meeks: Hi Xisco, Peter - Xisco is working on re-writing the wizards in Java :-) On Fri, 2011-07-01 at 16:05 +0200, Xisco Faulí wrote: Michael wrote: Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) Xisco wrote: Yes, you're right but if I have
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Xisco, Peter - Xisco is working on re-writing the wizards in Java :-) On Fri, 2011-07-01 at 16:05 +0200, Xisco Faulí wrote: Michael wrote: Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) Xisco wrote: Yes, you're right but if I have some time before gsoc finishes (or even after) I'd like to take a look to it. Who should I get in contact with in order to get my feet wet ? Ah - so the XSLT expert is Peter Jentsch who has done a load of great work in this area, writing the much faster / smaller native C++ filter etc. He can prolly help out with some code pointers, and/or perhaps some simple example XSLTs that might be useful for translating attributes / elements (?), and ways to get feed the required data to them elegantly. HTH, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
On Fri, 2011-07-01 at 16:32 +0200, Laurent Godard wrote: IIRC, templates can be deployed with extension mechanism Sounds fun :-) so why not use this and package language based extension when building the installer ? so, you may find more easily maintainers of these files Ah - so the problem is that we have tens if not more of Mb of entirely duplicated template files in our download and install - and that that is pretty pointless - when the changes are small between templates. Worse - since ~anything can be changed in a template, not just translation (and perhaps a few well flagged attributes), people tweak all manner of random stuff making cross-language consistency hard, and almost impossible to detect problems with (try diffing the formatted XML between two old-style apparently identical-but-for-l10n templates) :-) i think your proposal is intellectually the good one, but seems overkill to me regarding the efforts needed when the files will have to be updated Heh - sure, but using LibreOffice itself as a translation tool is somewhat fraught with difficulty ;-) cf. above - no doubt we could try to fix that: to expose language-adaptive document functionality in the UI, but I'd prefer to have some background heavy lifting just for our internal templates as of now :-) ATB, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
2011/6/30 Michael Meeks michael.me...@novell.com Hi Xisco, On Thu, 2011-06-30 at 18:28 +0200, Xisco Faulí wrote: Correct me if i'm wrong but as i've seen in the fax wizard,each kind of template has its own template so I believe it's the same for the letter templates and every localize has a different template, right ? Um ;-) in theory yes, but in reality no - having a duplicated ODF file for each and every translation (duplicating all the XML, all embedded images etc. etc.) bloated our install sets to some huge size for no good reason :-) In that case, the templates are the ones that should be changed, right ? Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) Yes, you're right but if I have some time before gsoc finishes (or even after) I'd like to take a look to it. Who should I get in contact with in order to get my feet wet ? All the best, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi michael In that case, the templates are the ones that should be changed, right ? Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. IIRC, templates can be deployed with extension mechanism so why not use this and package language based extension when building the installer ? so, you may find more easily maintainers of these files i think your proposal is intellectually the good one, but seems overkill to me regarding the efforts needed when the files will have to be updated thanks anyway for your leading :-) Laurent ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
2011/6/29 Cedric Bosdonnat cedric.bosdonnat@free.fr Hi Xisco, On Wed, 2011-06-29 at 01:23 +0200, Xisco Faulí wrote: Sorry for the delay but I had a visit last weekend and I wasn't able to work on it until yesterday night. What I've done during the week: - Improve the boot speed - Clean a bit the code - Show a message when a file is going to be overwritten - Load the previous configuration Where is your work available ATM? Could you please start merging it with master to get a build with all GSoc projects for midterms? http://cgit.freedesktop.org/libreoffice/components/?h=feature/gsoc2011_wizards The idea behind that isn't to have something 100% complete and working, but to show to the world what you've already done and get feedback. Now i'm working on saving the configuration after the wizard is finnished. I think it'll be done tomorrow. Cool, then it would be nice to have it in master! Ok, i'll merge it next week. Furthermore, I've already started to work on the letter wizard. Let's see If I can already commit something by the end of the week. I would be awesome if you could improve that wizard to get something based on localised templates... Letters aren't formatted in the same way across the world and that wasn't taken into account by the old wizard. Correct me if i'm wrong but as i've seen in the fax wizard,each kind of template has its own template so I believe it's the same for the letter templates and every localize has a different template, right ? In that case, the templates are the ones that should be changed, right ? Greetings -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Xisco, On Thu, 2011-06-30 at 18:28 +0200, Xisco Faulí wrote: Correct me if i'm wrong but as i've seen in the fax wizard,each kind of template has its own template so I believe it's the same for the letter templates and every localize has a different template, right ? Um ;-) in theory yes, but in reality no - having a duplicated ODF file for each and every translation (duplicating all the XML, all embedded images etc. etc.) bloated our install sets to some huge size for no good reason :-) In that case, the templates are the ones that should be changed, right ? Weelll - so you're both right; but really we need to grub about inside the templates themselves to add some improved translation scheme I think; now we have fast native XSLTs - I guess we could use the native XSLT filters to allow the templates to be self-standing, and yet adapt to the locale nicely. But - your task is primarily the Java - python conversion I guess :-) All the best, Michael. -- michael.me...@novell.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] [GSOC] Report #5. Wizards
Hi Xisco, On Wed, 2011-06-29 at 01:23 +0200, Xisco Faulí wrote: Sorry for the delay but I had a visit last weekend and I wasn't able to work on it until yesterday night. What I've done during the week: - Improve the boot speed - Clean a bit the code - Show a message when a file is going to be overwritten - Load the previous configuration Where is your work available ATM? Could you please start merging it with master to get a build with all GSoc projects for midterms? The idea behind that isn't to have something 100% complete and working, but to show to the world what you've already done and get feedback. Now i'm working on saving the configuration after the wizard is finnished. I think it'll be done tomorrow. Cool, then it would be nice to have it in master! Furthermore, I've already started to work on the letter wizard. Let's see If I can already commit something by the end of the week. I would be awesome if you could improve that wizard to get something based on localised templates... Letters aren't formatted in the same way across the world and that wasn't taken into account by the old wizard. -- Cédric Bosdonnat LibreOffice hacker http://documentfoundation.org OOo Eclipse Integration developer http://cedric.bosdonnat.free.fr ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[Libreoffice] [GSOC] Report #5. Wizards
Hello, Sorry for the delay but I had a visit last weekend and I wasn't able to work on it until yesterday night. What I've done during the week: - Improve the boot speed - Clean a bit the code - Show a message when a file is going to be overwritten - Load the previous configuration Now i'm working on saving the configuration after the wizard is finnished. I think it'll be done tomorrow. Furthermore, I've already started to work on the letter wizard. Let's see If I can already commit something by the end of the week. Greetings ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
