-----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

Reply via email to