I hate to be a PITA, but is there any reason in locales files that, for instance,
<single>book</single>
<multiple>books</multiple>
bk.
isn’t represented like this…
<single>book</single>
<multiple>books</multiple>
<short>bk.</short>
It would make parsing the file a whole lot easier.
Ron.
I hate to be a PITA, but is there any reason in locales files that, for
instance,
<single>book</single>
<multiple>books</multiple>
bk.
isn’t represented like this…
<single>book</single>
<multiple>books</multiple>
<short>bk.</short>
It would make parsing the file a whole lot easier.
You could also have …
book
books
bk.
bks.
… which would be tough to represent in a single node with just one
level of nesting.
What about…
bk.
bks.
book
books
IMHO, this would be more consistent and greatly simplify the parsing of terms.
Ron.________________________________________
From: Frank Bennett [@Frank_Bennett]
Sent: Sunday, February 14, 2010 10:02 PM
To: development discussion for xbiblio
Subject: Re: [xbiblio-devel] Terms
On Mon, Feb 15, 2010 at 11:49 AM, Jerome, Ron <@Jerome_Ron> wrote:
I hate to be a PITA, but is there any reason in locales files that, for
instance,
<single>book</single>
<multiple>books</multiple>
bk.
isn’t represented like this…
<single>book</single>
<multiple>books</multiple>
<short>bk.</short>
It would make parsing the file a whole lot easier.
You could also have …
book
books
bk.
bks.
… which would be tough to represent in a single node with just one
level of nesting.
Ron.
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
What about…
bk.
bks.
book
books
IMHO, this would be more consistent and greatly simplify the parsing of terms.
Certainly simpler to parse, but this change would raise a problem in
schema validation. The current schema guarantees that explicitly
singular and plural terms always come in matched pairs. You would
lose that guarantee, so the implementation would need to cope with
mismatched items gracefully. I think you’d find that results in
things getting complicated all over again.