<div><font color="#006600">Hi Regina and all the rest. </font><br/>
<br/>
<font color="#006600">First of all, I'm not (yet at least) a developer. That said I'll toss in my thoughts because I AM very concerned about the quality and accuracy of LibreOffice's built-in help.</font><br/>
<br/>
<font color="#006600">[May I suggest that all responses to this thread should utilize the Reply All mechanism but stay on topic. Private (off list) replies are not very helpful in a discussion like this.]</font><br/>
<br/>
<font color="#006600">Regarding concensus that the current built-in help will be retained: In my opinion something like it MUST exist. As frustrating as the current verbiage is, to toss it out entirely would be far worse. Rather, let's incrementally improve it.</font><br/>
<br/>
<font color="#006600">A</font><br/>
<font color="#006600">This seems to be common sense. (+1)</font><br/>
<br/>
<font color="#006600">B</font><br/>
<font color="#006600">I know nothing about this extension but if it makes it easier for "Joe Sixpack" (a run of the mill user of LibreOffice) to productively contribute to the quality of the built-in help then I'm all for it. (+1)</font><br/>
<br/>
<font color="#006600">C</font><br/>
<font color="#006600">Most emphatically,  yes. (+3) To improve its visibility to the user community someone should add a link to this wiki in the top level Help menu (something like "How to contribute to this Help")</font><br/>
<br/>
<font color="#006600">D</font><br/>
<font color="#006600">Way to go! Those who contribute any documentation, particularly in the early stages, need not be programmers who are battle scarred from waging the battle to build the software. (+2)</font><br/>
<br/>
<font color="#006600">-- <br/>
Jim</font><br/><br/>-----Original Message-----<br/>From: Regina Henschel <rb.henschel@t-online.de><br/>To: LO dev fdo <libreoffice@lists.freedesktop.org><br/>Cc: LO documentation <documentation@global.libreoffice.org><br/>Sent: Sun, 02 Aug 2015 10:07<br/>Subject: Ease maintenance of build-in help<br/><br/></div>Hi all,<br/>
<br/>
I have started a new thread so that the problem is not hidden inside <br/>
other threads or in private mails.<br/>
<br/>
First, is there consensus, that the current build-in help will be retained?<br/>
<br/>
If not, then the following ideas are useless and starting would be waste <br/>
of time. In such case, please stop me immediately.<br/>
<br/>
I collect here some ideas from some threads and mails:<br/>
<br/>
A<br/>
Authors of help texts are allowed to start in ODF to discuss and <br/>
finalize the content and appearance of the intended help texts. There <br/>
should be a place in the repository to store such files. This way <br/>
authors did not need deep knowledge of the technical structure of <br/>
helpcontent2. The person who integrates the help texts into the build-in <br/>
help need not be the content author.<br/>
<br/>
B<br/>
Improve the extension "HelpAuthoring" and fix its bugs. The extension <br/>
might be principally not suitable to generate the final version of a <br/>
help file, but it is useful as start, because it sets a lot of the <br/>
needed XML-elements and attributes automatically. The result might still <br/>
needs additions and corrections, but that is less work, than writing all <br/>
from scratch. Even if someone do not know all details about the help, he <br/>
can start and deliver a file, which other then can improve and integrate.<br/>
<br/>
C<br/>
Provide a development section about the build-in help to the Wiki. It <br/>
should not only contain a tutorial about help authoring but in addition <br/>
a description how the current help works at all from a developer view, <br/>
and how it is actually structured.<br/>
We can start with the document "OOo2HelpAuthoring.pdf". The content has <br/>
to be revised and adapted and extended. For example the .mk files are <br/>
different than described in that document and the document describes the <br/>
possibilities of the help format, but not all details of the actual <br/>
realization.<br/>
Having it in the Wiki keeps such knowledge available, when a help expert <br/>
leaves the community. It can be adapted to future developments. Experts <br/>
of different areas can better work together to collect help knowledge in <br/>
one place, for example experts for "Help to Wiki" and experts for <br/>
"translating help".<br/>
<br/>
D<br/>
It would ease work, when there would be a tool, that shows a .xhp file <br/>
the same way as it it shown in the help viewer, so that it is not needed <br/>
to build helpcontent2 every time when you test some changes in your way <br/>
to the final version. And authors who use "HelpAuthoring" need not be <br/>
able to build LibreOffice.<br/>
<br/>
Kind regards<br/>
Regina<br/>
<br/>
_______________________________________________<br/>
LibreOffice mailing list<br/>
<a href="mailto:LibreOffice@lists.freedesktop.org">LibreOffice@lists.freedesktop.org</a><br/>
<a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice">http://lists.freedesktop.org/mailman/listinfo/libreoffice</a><br/>