As usual, we have a clear vision of the goal we want to achieve and we know it fits perfectly in the framework available, but sometimes we don't get the smart idea the first time you look at the issue.
It was easy to do the proof of concept for the new help and the style sheet transformations, but in the hurry to get the concept, I used a pair of clutches, or plain bad solution, hoping to be able to come back later.
So time has come to fix the localization of the new Help strings, and to work to use the translation infrastructure of The Document Foundation.
The trick was under my eyes for long time. It is called document() function in XSLT. With the document() function, I can open an external document, and process it while transforming a XML file.
So why not call an auxiliary help file, with all User Interface strings translated, and use the results inside your main transformation? That is what I did in my latest patch, where I created a help file (browserhelp.xhp) with all terms of my User Interface.
So here is an excerpt of the document() function usage in the XSLT:
<!-- Strings for the help UI page -->
<xsl:variable name="tmp_href_ui"><xsl:value-of select="concat($urlpre,'text/shared/help/browserhelp.xhp')"/></xsl:variable>
<xsl:variable name="tmp_doc_ui" select="document($tmp_href_ui)"/>
<xsl:variable name ="ui_contents"><xsl:apply-templates select="$tmp_doc_ui//variable[@id='contents']"/></xsl:variable>
where I get the right location in tmp_href_ui and the document in tmp_doc_ui, and just after I get the string which identifier is 'contents'.
Later, I used the string 'contents' in the page like
Voilà. And while we are refactoring, I drop most the the other XSLT I was using as clutch (localized.xsl) and exercised some synapses in using the <xsl:for-each> statement to traverse the list of entries in the languages drop-down selector.