On Sat, Apr 30, 2011 at 6:44 PM, Sylvester Keil <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Apr 29, 2011, at 7:58 PM, Bruce D'Arcus wrote: > >> So am totally not following this. Can someone boil down the >> implications for the 1.0.1 discussion? > > Because Rintze suggested to include gender ordinals support in locales into > CSL 1.0.1, I wanted to point to another issue with ordinals which could be > easily fixed and included in a 1.0.1 release, too. > > The problem with the 1.0 schema is that it limits the ordinal definitions to > "ordinal-01" through "ordinal-04"; therefore it may not be possible to > transform all numbers into their correct ordinal form in all languages. In > fact, it is not even possible to do so in English. As a quick example > consider 13 and 23: they should become 13th and 23rd, but there is no way for > a cite processor to distinguish between the two if you have only defined the > ordinals 1-4: 13 and 23 would either become 13rd and 23rd, because both end > with 3 and ordinal-03 is defined as 'rd', or they would be become 13th and > 23th because they are both greater than 4. > > What I am suggesting is to alter the schema to allow for any number of > ordinal-** definitions. Using the algorithm I proposed, it would be > sufficient to define ordinals 0, 1, 2, 3, 11, 12, 13 in order to be able to > render all ordinals in English (unless I missed something). > > Consider this test case: > > https://github.com/inukshuk/citeproc-ruby/blob/master/features/locale/ordinalize.feature > > This is not legal CSL 1.0 because it contains ordinal definitions for 0, 11, > 12, and 13; however, by changing the CSL to be valid (i.e., instead of > ordinal-00 use ordinal-04 and remove ordinals 11, 12, 13), I don't think it > is possible to implement a processor that would produce the expected results > in all cases (either 11, 12, 13 or 21, 22, 23 would be wrong). > > The proposed change to the schema is 'harmless' in that does not render CSL > 1.0 styles invalid; furthermore, CSL 1.0 processors would still be able to > process 1.0.1 styles as if they were 1.0 styles (although they would not pass > schema validation). > > As regards the issue of gendered ordinals, I've just added a test to > illustrate a possible use case; perhaps Rintze or Frank could confirm if this > is correct? > > https://github.com/inukshuk/citeproc-ruby/blob/master/features/locale/gender.feature > > Sylvester
I would certainly support including this in a 1.0.1 release. Currently citeproc-js handles ordinals with an algorithm that is hard-coded to the English convention, with special handling for ordinals 11-13. Sylvester's approach would make it possible to use a truly general algorithm capable of covering all languages. It's a big win. Frank > > >> On Fri, Apr 29, 2011 at 5:47 AM, Sylvester Keil <[email protected]> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> >>> On Apr 29, 2011, at 10:50 AM, Frank Bennett wrote: >>> >>>> 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. >>> >>> Exactly. This way, each locale can decide which match-points to define; for >>> example, German would only have to define ordinal-00 = '.'; we could >>> include long-forms in this process, too, so that it is up to each locale >>> which long-forms to define. The algorithm is fixed in the sense, that it >>> assumes the number system uses a base 10; perhaps we could allow for a >>> locale to specify the modulus too? >>> >>> Sylvester >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (Darwin) >>> >>> iEYEARECAAYFAk26iR4ACgkQh4kzvOqyWhAwZgCeO8Y2Dvjc5ivBndCbDAMNjxpF >>> DsAAoMgDf9OQzOV8Mgu2Iyckit16zjEG >>> =LWOE >>> -----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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (Darwin) > > iEYEARECAAYFAk272gwACgkQh4kzvOqyWhCOOgCeJMUydEHkxKSnR7ye+MXMhUxT > 7YQAn2zLvJ+fd6RFm4zTTvP64y2Ky1MI > =+gZ3 > -----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
