On Fri, Apr 29, 2011 at 5:20 PM, Sylvester Keil <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Apr 28, 2011, at 7:35 PM, Rintze Zelle wrote: > >> On Thu, Apr 28, 2011 at 1:00 PM, Bruce D'Arcus <[email protected]> wrote: >> You're saying you want to fold in a backward-incompatible feature >> addition with a bug fix release? >> >> In this context, backward-compatibility is the ability of a CSL 1.0.1 >> processor to handle CSL 1.0 styles and locales, right? Then only the bug fix >> is backward-incompatible (as defining gender-specific ordinals in the CSL >> locales will always be optional). > > Because you brought up ordinals, I would just like to add that I think Rintze > is absolutely right in that including the gender support for locales will not > lead to issues for CSL 1.0 processor processing 1.0 locales. Furthermore, it > is not difficult for 1.0.1 processors to handle 1.0 locales; judging from > some of the citeproc-tests I believe that the proposal is implemented in > citeproc-js already? I definitely and to implement gender support for some of > the tests to pass. > > However, there was another issue I had to address in citeproc-ruby. For > illustrations purposes, you can take a look at the test cases here: > > https://github.com/inukshuk/citeproc-ruby/blob/master/spec/csl/locale_spec.rb > > The relevant tests are for '#ordinalize', lines 85 through 159. As you can > see on lines 92 and 100, I would expect 3 to become 3rd, 13 to become 13th, > 23 to become 23rd. This does not work with CSL 1.0 because I can only specify > the ordinals 1-4 (13 would probably become 13rd here). What's more, I would > expect that in different languages all kinds of exceptions are possible which > lead to similar problems. > > My implementation currently addresses this as follows: > > Given a a number X to ordinalize, I check the locales, following the normal > prioritization, for a definition of X; if X is not defined, the process is > repeated for Y = X % mod where mod currently starts at 100 and is divided by > 10 in every consecutive step. Therefore, to ordinalize 1155 I would try to > look up the following terms until there is a match: > > ordinal-1155 > ordinal-55 > ordinal-05 > ordinal-00 > > To ordinalize 113 the look-up would be for: > > ordinal-113 > ordinal-13 > ordinal-03 > ordinal-00 > > So, as you can see, for English, I would have to define the following minimal > set of ordinals to cover all cases (that I can think of right now): > > ordinal-00 = 'th' > ordinal-01 = 'st' > ordinal-02 = 'nd' > ordinal-03 = 'rd' > ordinal-11 = 'th' > ordinal-12 = 'th' > ordinal-13 = 'th' > > In the two examples above 1155 becomes 1155th and 113 becomes 113th, whereas > using a CSL 1.0 locale the algorithm would return 1155th and 113rd which is > wrong but consistent, I think, with CSL 1.0 expectations. That is to say, > allowing locales to define any number as an ordinal term should not alter the > behaviour of CSL 1.0 processors at all; furthermore, the results of a > processor using the above algorithm when using 1.0 locales is consistent with > current implementations, too.
Sylvester, Nice. So the idea is to use a fixed algorithm, and to control it by defining match-points in the locale files that will yield that right result for the language? This sounds very interesting. Frank > > One possible problem with this approach is that ordinal-00 is implicitly > treated as the default ordinal; given that 0 itself is likely to occur less > frequently than 4 (which acts like a default now) this is perhaps even an > improvement, but given a language that has a zero ordinal ending which is not > suitable as a default this quickly becomes problematic. Therefore, we could > add an explicit default ordinal-xx instead of the implicit ordinal-00. > > Sylvester > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (Darwin) > > iEYEARECAAYFAk26dOMACgkQh4kzvOqyWhAWoQCgmnJjs9kw4exAoypboq9hDkoV > FsEAoMbYAAedxStRoHcjAqa/qlASFS6T > =qOzS > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > xbiblio-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/xbiblio-devel > ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ xbiblio-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
