Re: [libreoffice-documentation] Re: Ease maintenance of build-in help

Hi guyz,

Why don't you use wiki as authoring tool, convert that to XML, then you have a source that can be 
converted to anything. You put the wiki into version control (git/subversion), power authors can 
edit the text files with ease in an editor of their choice (wiki syntax is easy to learn), others 
can use their browser.

‎Everybody can contribute to the doc in an easy way, wikipedia-style documentation.

Regards,

HP

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Thorsten Behrens
Sent: Tuesday, 4 August 2015 17:11
To: Regina Henschel
Cc: LO dev fdo; LO documentation; Jan Holesovsky
Subject: [libreoffice-documentation] Re: Ease maintenance of build-in help

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

-- 
To unsubscribe e-mail to: documentation+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/documentation/
All messages sent to this list will be publicly archived and cannot be deleted