On Sep 5, 2012, at 1:33 PM, Rintze Zelle wrote:

> 
> 
> On Wed, Sep 5, 2012 at 7:20 AM, Frank Bennett <[email protected]> wrote:
> On Wed, Sep 5, 2012 at 8:12 PM, Frank Bennett <[email protected]> wrote:
> > On Wed, Sep 5, 2012 at 8:06 PM, G C <[email protected]> wrote:
> >> Frank, I tried the latest mlz release with a style which re-defines
> >> ordinals, gender, etc.
> >> This doesn't work.
> >> -limit-day-ordinals-to-day-1="true" has no effect.
> >
> > I haven't implemented that one yet, so no worries there.
> >
> >> -when gender variants are defined in the ordinal suffix terms , there is no
> >> output at all with terms other than months (e.g. "edition")
> >> [<term name="ordinal-01" gender-form="feminine"
> >> match="whole-number">ʳᵉ</term>
> >> <term name="ordinal-01" gender-form="masculine"
> >> match="whole-number">ᵉʳ</term>]
> >
> > That's not good. Thanks for the report, I'll take a look.
> 
> Is that the entire set of ordinals that are redefined in the style?
> You need to provide the full set, and I think that a default term
> (without gender-form) for each needs to be set. The ordinals travel
> only as a full set.
> 
> Is that really necessary? The example I wrote up for the specification 
> doesn't define a genderless "ordinal-01" term.

I was wondering, too. Gracile explained that there is no genderless term in 
this case and Rintze suggested to generally fallback to the feminine version 
when looking up terms since that is the more common case in the languages we 
looked at.

Note: I haven't worked out a general algorithm for gender lookups yet that 
considers all these fallbacks.

Sylvester

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Reply via email to