Ease maintenance of build-in help

[Thorsten Behrens]

Regina Henschel wrote:
> I have started a new thread so that the problem is not hidden inside other
> threads or in private mails.
> 
Thanks a lot!

> First, is there consensus, that the current build-in help will be retained?
> 
I think - the plan to go all-in for wiki-based help is on hold, until
someone (Kendy?) has cycles to push it further.

Would perhaps be good to extend
https://wiki.documentfoundation.org/Development/Wikihelp with some
status/plans/more details on what is missing where.

> A
> Authors of help texts are allowed to start in ODF to discuss and finalize
> the content and appearance of the intended help texts. There should be a
> place in the repository to store such files. This way authors did not need
> deep knowledge of the technical structure of helpcontent2. The person who
> integrates the help texts into the build-in help need not be the content
> author.
> 
Makes sense. For storing those WIP versions in the repo, I'm not sure
that gives us much. Perhaps collaboration via owncloud or wiki works
better there?

> B
> Improve the extension "HelpAuthoring" and fix its bugs. The extension might
> be principally not suitable to generate the final version of a help file,
> but it is useful as start, because it sets a lot of the needed XML-elements
> and attributes automatically. The result might still needs additions and
> corrections, but that is less work, than writing all from scratch. Even if
> someone do not know all details about the help, he can start and deliver a
> file, which other then can improve and integrate.
> 
Having a list of EasyHacks / Bugs somewhere would be a great
start. And a possible topic for one of the upcoming hackfests.

> C
> Provide a development section about the build-in help to the Wiki. It should
> not only contain a tutorial about help authoring but in addition a
> description how the current help works at all from a developer view, and how
> it is actually structured.
> We can start with the document "OOo2HelpAuthoring.pdf". The content has to
> be revised and adapted and extended. For example the .mk files are different
> than described in that document and the document describes the possibilities
> of the help format, but not all details of the actual realization.
> Having it in the Wiki keeps such knowledge available, when a help expert
> leaves the community. It can be adapted to future developments. Experts of
> different areas can better work together to collect help knowledge in one
> place, for example experts for "Help to Wiki" and experts for "translating
> help".
> 
Quite.

> D
> It would ease work, when there would be a tool, that shows a .xhp file the
> same way as it it shown in the help viewer, so that it is not needed to
> build helpcontent2 every time when you test some changes in your way to the
> final version. And authors who use "HelpAuthoring" need not be able to build
> LibreOffice.
> 
Sounds like another obvious Easy/HardHack idea for a Hackfest? ;)

Cheers,

-- Thorsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150804/6619ff4b/attachment.sig>