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
signature.asc
Description: Digital signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
