OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: DOCBOOK-APPS: Sorting and non-en_US indexes

For the record here's the correct way to do what I was describing in a
previous post
. The code in the previous post had some stupidities. For this to work,
you need to have the alphabet in the gentext language files
(common/en.xml etc) for your target languages (even when they lack
upper/lowercase distinction), tho it should fallback to English if
there's no key in the language specified. As I understand it, the
language is going to come from the value of the lang attribute on the
index's parent, correct (the value that comes from <xsl:call-template
name="l10n.language"/>  in common/l10n.xsl)? Should that same value be
used to set the lang attributes on the xsl:sorts in autoidx.xsl? 

<!-- Change the following entities in the internal subset of
<!ENTITY lowercase "f:lowercase()">
<!ENTITY uppercase "f:uppercase()">

<!-- SNIP -->

<!-- add some stuff to the xsl:stylesheet element-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";

<!-- add these two elements to the top level of the autoidx.xsl
stylesheet -->
  <saxon:function name="f:uppercase">
	<xsl:variable name="uppercase">
	  <xsl:call-template name="gentext.element.name">
	<saxon:return select="normalize-space($uppercase)"/>

  <saxon:function name="f:lowercase">
	<xsl:variable name="lowercase">
	<xsl:call-template name="gentext.element.name">
	  <saxon:return select="normalize-space($lowercase)"/>

<!-- SNIP -->

As useful as they sound, I haven't used xml catalog files yet. Instead
of having several autoidx.xsls (which sounds unpleasant), could you have
one and get the alphabet with document('[level of indirection here,
resolved with catalog files to en.xml or target
lang.xml]')//l:gentext[@key = 'lowercase.alpha']/@text? But then you
lose the fallback mechanism to English if that language doesn't have
those keys. Or you could have a bunch of language.ent files and pull in
the right one as a parameter entity using catalog files. 

The <saxon:function>s are ignored by non-Saxon processors, correct? So
they could be included in the distribution and it could be documented
that you can use them with <!ENTITY lowercase "f:lowercase()"> <!ENTITY
uppercase "f:uppercase()">. Everything seems a little messy--not sure
what a good general solution is. I still have some work to do in pulling
everything together myself. 


> -----Original Message-----
> From: Jirka Kosek [mailto:jirka@kosek.cz]
> I have one another idea how to make this processor idependat. You can
> create several versions of autoidx.xsl with different upper and
> lower-case entites and lang in xsl:sort. When invoking transformation
> you provide different XML catalag for each language to XSLT procesor.
> This catalog can redirect request for autoidx.xsl to proper localized
> version.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC