[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re^6: some suggestions for docreg

Am 04.05.98 schrieb apharris # burrito.onshore.com ...

Moin Adam!

APH> That's a technical problem and has technical solutions.  Say we have a


APH> local knob for the local sysadmin saying "do prefer German
APH> documentation".  Then a format could provide a translation of the
APH> section and the abstract.  Perhaps when both English and German are
APH> available, German is presented instead.

I can#t see the connection. You#ve suggested the following:

  DocID: bla
  Title: Printing HOWTO
  Abstract: Descripes printing on a Linux system

  File: ppp-howto.html
  Language: en

  File: DE-PPP-HOWTO.html
  Language: de

And this will *not* work. I want a *German* description. So we need one  
entry/language, but of course we could use the same DocID. But I would  
prefer a link to the other DocID:

  DocID: bla
  Title: Printing HOWTO
  Abstract: ...

  File: ppp-howto.html
  Language: en

  DocID: bla-de
  DocID_orig: bla
  Title: Drucker HOWTO
  Abstract: Beschreibt das Drucken unter Linux

  File: DE-PPP-HOWTO.html
  Language: de

With this syntax I have descriptions in both languages. And we need such a  
feature like DocID_orig for packages like doc-linux-<language>, because  
the HOWTOs are in several packages.

APH> real-world representation.  We must stick to these abstractions unless
APH> there's a *real* *good* reason to break them.  This is not such a
APH> reason.

I don#t understand that. Please descripe, how you would solve this  
problem. I don#t see your solution.

APH> Consider if we had 7 different transations of the SCSI FAQ, all as
APH> different entities; how could we manage them as one document per se?
APH> We couldn't.  So we're diluting the operative power of our own
APH> abstractions.

I don#t understand your point. Could you give an example?

APH> The operative issues there are whether documents need to be
APH> *constrained* to the domain or whether the domain may be extended in
APH> certain situations.  My view is that the domain ought to be
APH> constrained but that a document may also be able to define a "scope"
APH> (i.e., gcc) which is a leaf on the DDH node tree.

I don#t understand that. Sorry. Are you talking about the possiblity to  
create new sections? We#re talking about documents and not about sections!

APH> Marco, over and over again you seem to lose sight of the operative
APH> abstractions.


APH>  Please try to keep those abstractions at the front of
APH> your mind and forget the technical issues for now.  I believe in

Sorry, but translations are important for the standard. I#m not talking  
about the titles of sections! I#m talking about titles and abstracts of  
documents. And this problem is very important for our standard.

APH> strong abstractions first, code later;

I#ve never talked about the code. Once again:

  1.) German documents need a description/title in German, French ...
      German documents *don#t* need a description/title in English!
      => we can#t have more than one Language/DocID

  2.) We need a connection between a document in several languages.
      Therefor we need something like DocID_orig:

As German user I don#t want English descriptions/titles of German  

APH> I also believe in keeping it
APH> simple.


cu, Marco

Uni: Budde@tu-harburg.de           Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com    http://www.tu-harburg.de/~semb2204/

To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: