docutils-develop

[Docutils-develop] More bibliographic fields: `translator` / `translators` ?

[Adam C. <ad...@ch...>]

Hi.

What do you think about adding an/two extra bibliographic fields, namely
`translator` and `translators`? I think it could be useful, and I have a case
coming up where this would be useful for me... 

One could argue that one should add the translator(s) to the `authors` field,
but you normally make a distinction between those who wrote the original
content and the ones who translated it into a different language.

Comments?

Implementation should be fairly trivial, as it would basically be copying the
code for the 'author' field and changing the relevant. If you wanted, I guess
you could get more creative and make a new baseclass for this type of feature
("NameList"?) and let the `author` and `translator` classes inherit from
that...

---
Adam Chodorowski <ad...@ch...>

I am returning this otherwise good typing paper to you because someone has 
printed gibberish all over it and put your name at the top.
    -- Ohio U. English professor 

Re: [Docutils-develop] More bibliographic fields: `translator` / `translators` ?

[David G. <go...@us...>]

Adam Chodorowski wrote:
> What do you think about adding an/two extra bibliographic fields, namely
> `translator` and `translators`?

I think something could be done to accommodate this.  I've been thinking of
adding other fields, such as "reference" (for web site URLs).  I believe
Tony Ibbs would like to see "dedication".

Perhaps, in addition to the current fixed set of recognized fields, we could
have a generic bibliographic field where both the field name and the field
body are user-specified.  The set of recognized fields are useful, since
many have specialized processing.  But currently, if there's an unrecognized
field in the bibliographic field list, it's left out of the "docinfo"
element as a field of a separate, ordinary field list (the original field
list is split in two).  Maybe it's time to rethink that, and make a
general-purpose solution instead of tacking on individual cases one after
another.  Adding a field_list field to the content model of "docinfo" would
do the trick.  Then "docinfo" itself could be thought of as a specialized
field_list.

-- 
David Goodger  <go...@us...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/

Re: [Docutils-develop] More bibliographic fields: `translator` / `translators` ?

[Adam C. <ad...@ch...>]

On Wed, 24 Jul 2002 01:17:05 -0400 David Goodger
<go...@us...> wrote:

> Adam Chodorowski wrote:
> > What do you think about adding an/two extra bibliographic fields, namely
> > `translator` and `translators`?
> 
> I think something could be done to accommodate this.  I've been thinking of
> adding other fields, such as "reference" (for web site URLs).  I believe
> Tony Ibbs would like to see "dedication".
> 
> Perhaps, in addition to the current fixed set of recognized fields, we could
> have a generic bibliographic field where both the field name and the field
> body are user-specified.  The set of recognized fields are useful, since
> many have specialized processing.  But currently, if there's an unrecognized
> field in the bibliographic field list, it's left out of the "docinfo"
> element as a field of a separate, ordinary field list (the original field
> list is split in two).  Maybe it's time to rethink that, and make a
> general-purpose solution instead of tacking on individual cases one after
> another.  Adding a field_list field to the content model of "docinfo" would
> do the trick.  Then "docinfo" itself could be thought of as a specialized
> field_list.

Yes, I think this is a very good idea. People are bound to come up with some
extra bibliographic fields they would like to use, so this is the only good
way to accomodate all of them.

However, there is a slight problem for handling fields which contain list of
eg. names (as "authors" does and "translators" would do) as this is a totally
specialized thing currently. I think it would make sense to create a general
inline markup for "horizontal lists" (field lists, bulleted lists, etc being
vertical ones) one could use in this (and other cases). This way people could
even add their own "authors"-style bibliographic fields, and get them
processed automatically in a similar way...

---
Adam Chodorowski <ad...@ch...>

Remember, any design flaw you're sufficiently snide about becomes a feature.
    -- Dan Sugalski

Re: [Docutils-develop] More bibliographic fields: `translator` / `translators` ?

[David G. <go...@us...>]

[David]
>> Perhaps, in addition to the current fixed set of recognized fields,
>> we could have a generic bibliographic field where both the field
>> name and the field body are user-specified.

[Adam]
> Yes, I think this is a very good idea. People are bound to come up
> with some extra bibliographic fields they would like to use, so this
> is the only good way to accomodate all of them.

A generic docinfo field is implemented in the latest CVS & snapshots.
This causes some behavior to change.  Previously, any unrecognized
fields were split off from the docinfo and became a separate
(ordinary) field list.  No longer; now they become generic fields.

I've also added "Dedication" as a registered field.  Like "Abstract",
"Dedication" is turned into a topic, but with 'class="dedication"' so
that it can be independently styled.

> However, there is a slight problem for handling fields which contain
> list of eg. names (as "authors" does and "translators" would do) as
> this is a totally specialized thing currently. I think it would make
> sense to create a general inline markup for "horizontal lists"
> (field lists, bulleted lists, etc being vertical ones) one could use
> in this (and other cases). This way people could even add their own
> "authors"-style bibliographic fields, and get them processed
> automatically in a similar way...

The "authors" field processing transforms a list into multiple
"author" elements.  In other words it takes a single plural field
containing a list and transforms it into multiple single fields.  Some
kind of mapping of plural to singular forms is required (currently
"authors" -> "author" is hard-coded).  I don't see how to automate
such a transform on arbitrary fields.  Field names ending in "s" isn't
a sufficient criterion, even in English ;-).  In any case, I'm not
sure that more special-casing is a good idea.

I suggest simply using a bullet list if you want a vertical list, or
punctuation-separation if you want a horizontal list::

    :Translators: - Me
                  - Myself
                  - I
    :Translators: Me; Myself; I

This should be easily understood by readers.  Is there any reason the
underlying markup should be more specific?

-- 
David Goodger  <go...@us...>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/