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
.? (1)
.? (2)
.? (3)
.? (4)
.?? (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
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]
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
.? (1)
.? (2)
.? (3)
.? (4)
.?? (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
Thanks for checking, I’ll take a look. We’re getting close!
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?
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.