Ease maintenance of build-in help

[Markus Mohrhard]

Hey,

I'll take the freedom to just answer some of the wikihelp related points.

On Sat, Aug 15, 2015 at 10:30 PM, Regina Henschel <rb.henschel at t-online.de>
wrote:

> Hi Jan,
>
> Jan Holesovsky schrieb:
>
>> Hi Regina,
>>
>> Regina Henschel píše v Ne 02. 08. 2015 v 19:06 +0200:
>>
>> I have started a new thread so that the problem is not hidden inside
>>> other threads or in private mails.
>>>
>>> First, is there consensus, that the current build-in help will be
>>> retained?
>>>
>>
>> Thank you for your thoughts on this topic - and sorry for my late reply.
>>
>
> I'm late too. That happens for persons, who can only contribute in their
> spare time.
>
> In the ideal world, I'd like the help be handled like this:
>>
>> * wikihelp is the authoritative source, with appropriate approval system
>>    etc. [easy for casual contributors to fix stuff in the help, but safe
>>    & easy to keep the standards]
>>
>> * existing translations converted so that there is no additional work
>>    for the translators when converting to wikihelp (once)
>>
>
> A workflow is needed for new content and for new languages. When the
> built-in help is automatically generated, the translated Wikihelp needs to
> follow a strong structure.
>
>
>> * built-in help is generated from the wikihelp + translatios, and shown
>>    in the browser (JavaScript used for the indexing & search), instead of
>>    the home-grown help system
>>
>
> The part "extended tips" is missing in this scenario.
>

We have already a working solution for the extended tooltips. There is a
script to extract them from the help and maintain them independently. As
far as I known Caolan is even thinking about adding support for extended
tooltips to the ui files.


>
>
>> Currently we have the following pieces of the puzzle:
>>
>> * ability to convert .xhp's -> wiki format
>> * ability to convert wiki format -> html
>>
>> The indexing IIRC is not retained at the moment, and also the JavaScript
>> indexing is not implemented; so the switch is impossible in the current
>> state.  I am unable to work on this, but would be extremely happy to
>> mentor anybody who would be willing to help.
>>
>
> The Contents part (that what is generated from the *.tree files) is
> missing too. In addition the current Wikihelp misses reducing the UI, and
> the global search of the Wiki is no replacement for the search features of
> the built-in help.
>

That is what Kendy means with missing JavaScript code. The plan would be to
implement a search and index through Javascript. Actually there are wikis
which provide this feature similar to the way we do it in the build-in help
right now. So this is one of the required steps before we could switch to
wikihelp.


>
>
>> For the wikihelp itself, it might be possible to use the Mozilla's
>> Kitsune (the engine behind support.mozilla.org):
>>
>> https://github.com/mozilla/kitsune
>>
>> but that needs checking - whether it is better for our purposes than the
>> 'normal' mediawiki or not.
>>
>>
> I don't know about it; no comment.
>
>
>
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150816/4ee92a3e/attachment.html>