On Sat, Apr 30, 2011 at 6:44 PM, Sylvester Keil <sylvester@...> 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 <sylvester@...> 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 <sylvester@...> 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 <bdarcus@...> 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
>>> xbiblio-devel@...
>>> 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
>> xbiblio-devel@...
>> 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
> xbiblio-devel@...
> https://lists.sourceforge.net/lists/listinfo/xbiblio-devel
>
|