On Fri, Sep 7, 2012 at 9:42 AM, Frank Bennett <[email protected]> wrote: > On Fri, Sep 7, 2012 at 9:37 AM, Frank Bennett <[email protected]> wrote: >> On Fri, Sep 7, 2012 at 9:15 AM, Frank Bennett <[email protected]> wrote: >>> On Fri, Sep 7, 2012 at 8:31 AM, G C <[email protected]> wrote: >>>>> Date: Thu, 6 Sep 2012 12:28:12 +0900 >>>>> From: Frank Bennett <[email protected]> >>>>> Subject: Re: [xbiblio-devel] CSL 1.0.1 release >>>>> To: development discussion for xbiblio >>>>> <[email protected]> >>>>> Message-ID: >>>>> <cajgpgga1wvdvf156gxjbmqjnqg7zsr_j+ak1huuszqsj7bu...@mail.gmail.com> >>>>> Content-Type: text/plain; charset=UTF-8 >>>>> >>>>> On Wed, Sep 5, 2012 at 10:56 PM, Frank Bennett <[email protected]> >>>>> wrote: >>>>> > On Wed, Sep 5, 2012 at 10:13 PM, Rintze Zelle <[email protected]> >>>>> > wrote: >>>>> >> On Wed, Sep 5, 2012 at 7:41 AM, Sylvester Keil <[email protected]> >>>>> >> wrote: >>>>> >>> >>>>> >>> Note: I haven't worked out a general algorithm for gender lookups yet >>>>> >>> that >>>>> >>> considers all these fallbacks. >>>>> >> >>>>> >> >>>>> >> The scheme I had in mind is this: >>>>> >> >>>>> >> - if the target noun is neuter, only the neuter gender-variants are >>>>> >> taken >>>>> >> into consideration >>>>> >> - if the target noun is feminine (or masculine), both the feminine (or >>>>> >> masculine) and neuter gender-variants are taken into account. If an >>>>> >> ordinal >>>>> >> term exists both as a feminine (or masculine) and a neuter variant, the >>>>> >> feminine (or masculine) variant is used >>>>> >> >>>>> >> For example, with >>>>> >> >>>>> >> <term name="ordinal">.?</term> (1) >>>>> >> <term name="ordinal-01">.?</term> (2) >>>>> >> <term name="ordinal-01" gender-form="masculine">.?</term> (3) >>>>> >> <term name="ordinal-01" gender-form="feminine">.?</term> (4) >>>>> >> <term name="ordinal-02" gender-form="masculine">.??</term> (5) >>>>> >> >>>>> >> * if the target noun is neuter, term definitions 1 and 2 are taken into >>>>> >> account >>>>> >> * if the target noun is feminine, term definitions 1 and 4 are taken >>>>> >> into >>>>> >> account >>>>> >> * if the target noun is masculine, term definitions 1, 3 and 5 are >>>>> >> taken >>>>> >> into account >>>>> >> >>>>> >> Rintze >>>>> > >>>>> > Okay, that's helpful. >>>>> >>>>> So it was a quick month. >>>>> >>>>> I've put up a fresh release of MLZ (m245) that works with the updated >>>>> fr-FR locale and handles the above example as per Rintze's description >>>>> of the gender fallback logic on ordinals. >>>>> >>>>> What threw me is that the fallback priorities on ordinals differ from >>>>> those for straight terms (at least in my implementation). Terms always >>>>> have a hard-wired default value (assigned now according to the logic >>>>> of my earlier post). Getting that right was tricky, because the >>>>> default priorities can't be evaluated until the full set of ordinal >>>>> terms is known. Ordinals need to steer clear of the default unless it >>>>> was a non-gendered term assigned explicitly. >>>>> >>>>> In any case, I'm pretty confident that it's right now, but it hasn't >>>>> been extensively tested. Please try to break it; if problems turn up, >>>>> we'll fix them. >>>>> >>>>> Frank >>>> >>>> Frank, >>>> >>>> With the latest release (3.0m246): >>>> >>>> -dates: ok ("limit-ordinals-to-day-1" works) >>>> -"issue", "volume": ok >>> >>> Yay. >>> >>>> >>>> There's still a problem with "edition": I always get the "general" ordinal >>>> suffix ("e" in fr-FR). But it's not correct when the edition is the first >>>> one: it should be "1re éd." ("edition" is defined as "feminine" in the >>>> locale-fr-FR.xml). The processor, with the "edition" variable, disregards >>>> the gender variants and choose the "general" suffix. >>>> >>>> [same results with a generic style (e.g. Chicago) or a custom style which >>>> redefines the locale terms] >>>> >>>> Thanks, >>>> Gracile >> >> This works for me. In the fr-FR locale, I get 1re for first edition. >> Same result in the processor test-bed and in MLZ m246, both via the >> test pane and in word processor documents. >> >> The discrimination turns on the locale and plain vanilla Javascript >> logic in the processor. I'm not sure why we would be getting different >> results. It's unlikely to turn anything up, but can you send me a copy >> of the custom style and an item that shows the error? >> >> Frank > > Belay that thought. With CMS Fullnote only, I get the masculine > suffix. Checking ... > > Frank
Gregoire: The 1re edition failure should be fixed in the latest MLZ update. Thanks for reporting; I picked up another bug that would have affected multi-locale styles while tracking down this one. Frank ------------------------------------------------------------------------------ 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
