Egon Schmid wrote:
> I don´t have something against a rendering a "see also" block. But
> rendering the content with a list would be a nightmare. We had a
> discussion at which place should be comma in this list. This depends
> on the language and I can guess it will be look very funny in
> Arabic.
localisation? ever heard of? easier to do in one place in the
stylesheets than in every function reference during translation
>> Ultimately, you guys (Egon, Goba, Harmut) should agree on correct
>> markup pattern. I just offered my opinion from DocBook markup
>> point of view.
>
> If Goba and Hartmut ignores me, so we will have never a agreement.
getting a 100% consensus in a project like this is rather impossible,
so everyone has to be prepared to be outvoted from time to time
as long as you are not open to sensible arguments and just come
up with "don't do so", "i told you not to do so", "it won't work"
and (*) "it would be a nightmare" without backing this with arguments
and without even having seen what it would be like you have
dislosed yourself from the process of decision finding
(*) no comma before the and in conformance with the
University of Minnesota Style Manual
>>>It is much better to write the "see also" notes
>>>as before. Indeed it will be too complex if you consider the
>>>
> other
>
>>>languages with different rules for rendering.
>>>
>
>>I see no problem here, if you are afraid of localizations of "see
>>
> also"
>
>>this is not problem as there is localization for this string
>>
> already
>
>>present in stylesheets.
>>
>
> You can do so, but don´t make a list.
please come up with *substantial* argument against a list
type of environment
the see-also sections in the function reference *are* lists,
or lets say enumerations, of pages elsewhere in the manual
right now the structure of this information is hidden in
plain text with <function> tags embedded into it
makes no use but generation the exact text with links into
it, but the information that it is a see-also list is hidden
at the content level while it should be on the structure
level as this would allow reuse of the see-also inter-
dependencies
easier localisation would be another point
for the exactly same reason we use <funcsynopsis> and friends
for the prototypes instead of just copying the function prototype
with arguments and return value from the source code and past it
into the manual as is
--
Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77
