On Sat, Apr 30, 2011 at 2:58 AM, Bruce D'Arcus <[email protected]> wrote: > So am totally not following this. Can someone boil down the > implications for the 1.0.1 discussion?
This is cross-talk, not relevant to the immediate 1.0.1 discussion. Nice solution, though. I'll open a ticket for it in the schema tracker. > > 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 > ------------------------------------------------------------------------------ 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
