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 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
