LibreOffice WikiHelp

Hi all,

> Either way, the good news is that I am currently uploading the files,
> and I'll make the site online as soon as it finishes, and I do few
> trivial checks; it should be later today (ETA 5 more hours, I am
> populating the database through the Mediawiki API, not directly). So
> far I am uploading only the English version.
>
> It will be read-only until RC2, so that it is easy to report bugs
> against the tooling that converts the help from the format that is used
> in the source code. After RC2, I plan to open it for your edits &
> improvements :slight_smile:

http://help.libreoffice.org is now up and running. As explained above,
it is not open for public editing yet. There are few known bugs already
filed in the bugzilla, should you find more, please report them too,
with 'wikihelp: ' in the subject, and assign them directly to me.

The already reported bugs are:

https://bugs.freedesktop.org/show_bug.cgi?id=32173
https://bugs.freedesktop.org/show_bug.cgi?id=32174

You can either test the wikihelp directly from LibreOffice RC1, by
issuing help on various parts of the suite (if you find something that
leads to non-existing page, please report it too), or just from your
browser, using 'Random page' in the left hand menu, and visually
scanning it :slight_smile:

I'll improve the tooling according to your findings, and upload the
improved versions of the pages.

I got just 2 additional bugreports, I am not sure it is enough :wink:

https://bugs.freedesktop.org/show_bug.cgi?id=32290
https://bugs.freedesktop.org/show_bug.cgi?id=32291

All four are fixed now, but please - really test it. Until we are sure
that the quality of the conversion tool is good enough, it makes no
sense to upload the l10n versions of the help - it would unnecessarily
blow the size of the database with every improvement of the conversion
tool.

I have heard quite some complaints about the missing native language
versions already; I am not sure I've explained it well enough
previously, but this testing is blocking it. So please - help me :slight_smile:

Thank you,
Kendy

Hi Kendy, :slight_smile:

I got just 2 additional bugreports, I am not sure it is enough :wink:

https://bugs.freedesktop.org/show_bug.cgi?id=32290
https://bugs.freedesktop.org/show_bug.cgi?id=32291

All four are fixed now, but please - really test it.  Until we are sure
that the quality of the conversion tool is good enough, it makes no
sense to upload the l10n versions of the help - it would unnecessarily
blow the size of the database with every improvement of the conversion
tool.

I have heard quite some complaints about the missing native language
versions already; I am not sure I've explained it well enough
previously, but this testing is blocking it.  So please - help me :slight_smile:

Personally, I'm taken up this weekend with other work for LibO but,
next week when I have more time, I will definitely look at the
WikiHelp and do my best to provide practical help.

David Nelson

Firefox warns that the connection is untrusted. (I think the warning comes from Google, which analyzes the threat from each site).

I did not visit the site because of that. Many more people may be avoiding the site in a similar manner.
Please ask the web master to take care of the issue (or contact Google to remove the false positive).

Then you will get many more volunteers.

Thanks.

-Narayan

Known problem related to the free cert used. For some reason browsers do not accept the cert which leads to the report.

Hi Kendy,

I have heard quite some complaints about the missing native language
versions already; I am not sure I've explained it well enough
previously, but this testing is blocking it. So please - help me :slight_smile:

Any chance of getting entries for the Base Module, and Basic / Macros ?

Thanks,

Alex

Hi Kendy,

I have heard quite some complaints about the missing native language
versions already; I am not sure I've explained it well enough
previously, but this testing is blocking it. So please - help me :slight_smile:

Any chance of getting entries for the Base Module, and Basic / Macros ?

Thanks,

Alex

Hi Kendy,

Hi all,

[...]

I have heard quite some complaints about the missing native language
versions already; I am not sure I've explained it well enough
previously, but this testing is blocking it. So please - help me :slight_smile:

I've search for your explanation on our list but didn't find them. Currently we (the localizer team) do not want the localized help to be uploaded on the wiki until we know about the localization process that will be in place.

We are the one doing the work and it's a very big work, so please, answer the questions we have asked.
What if we open the git repository to anybody tomorrow? will you stay there and spend your nights correcting the bugs newcomers have done or those not taking care of your previous work? No, you'll go away from such a project that do not care about your contributions and the quality of its product.

So please, please again, answer the questions Martin asked, the questions I asked, see Rimas and Jean-Baptiste mails too. And do not open the wiki until we all agreed on the workflow, it's really important for our localization team.
Thanks in advance
Kind regards
Sophie

Hi Sophie,

> I have heard quite some complaints about the missing native language
> versions already; I am not sure I've explained it well enough
> previously, but this testing is blocking it. So please - help me :slight_smile:

I've search for your explanation on our list but didn't find them.
Currently we (the localizer team) do not want the localized help to be
uploaded on the wiki until we know about the localization process that
will be in place.

I have subscribed to the l10n mailing list just on Friday, after I
learned that there were some discussions there I was not aware of until
then.

Now, the explanation about wikihelp. As you may recall, the conclusion
was described as:

  create help-packs - split out the help for each language
  and simply have no help installed[1], but a web link to on-line
  help[2], and a "download your help-pack here" direction
    + not even English help would be installed -
      this will save us 11Mb in the 170Mb download

Also, each and every release notes of betas and even RC1 contained a
note "The help content is not included. We are working on the online
version. Alternatively, it will be possible to install it separately."

It is my mistake that I did not explain the exact way to implement it in
advance, I am sorry for that.

So let me explain why wikihelp:

Wiki is so far the best free tool for collaboration editing I know of.
It gives anyone the freedom to improve things. With help implemented as
a wiki, any user of the suite can (potentially) just describe the
functionality better, should he/she find out that something is described
wrongly, or just partially.

Also, why should be your native language just a translation of an
English help? Should you have people that can improve the help, but
cannot speak English, why should they be bound to translating only, when
they can author the text? Why should be the French help just a
translation of an English help, when it can be an own (better?) version?

This is why I believe implementing the help as a wiki is the best thing
to do. How does it work:

- for 3.3, I am converting the .xhp files into wiki markup
  - it is now online as http://help.libreoffice.org
  - missing translations yet, I need to polish the tooling first
  - when the tooling is right, I'll add 2-3 more languages, for more
    testing
  - when even that approved, I'll upload the rest

- anything untranslated in the localized versions will be marked
  appropriately
  - a template for that, like {{NeedsTranslation}} + the English version

- after the import is done, and people are happy with it, it will be
  open for account creation
  - for now, please ask me directly if you want to have an account
    there, to edit pages like Main_Page, or Template:*
  - other pages might get rewritten by the import tooling

- after 3.3, I'll start to work on tooling to convert it back to offline
  help
  - to platform native help system
    - Windows/Linux/MacOSX
  - from the engineering point of view, we don't want a home-grown help
    system, as we have now
  - needs more research, to see if we don't lose features etc.

- when done, the wikihelp becomes the authoritative version of the help
  - but we'll still be able to incorporate changes from the .xhp files,
    when merging from OOo
  - we can agree that some of the localized versions would be locked for
    editing, and just taken from .xhp and .sdf files, but I _strongly_
    advise against that

Open questions:

- extended tips
  - cannot be part of the wikihelp, most probably these have to be
    handled separately, and translated using the normal process

- anything else?

We are the one doing the work and it's a very big work, so please,
answer the questions we have asked.
What if we open the git repository to anybody tomorrow?

As you might have noticed, anybody can ask for the git account, and
anybody with a bigger contribution is offered with write access.

will you stay
there and spend your nights correcting the bugs newcomers have done or
those not taking care of your previous work?

Oh? Were you following what we are doing on the development mailing
list? The last months, we have spent days and nights reviewing and
fixing patches from new people.

No, you'll go away from
such a project that do not care about your contributions and the quality
of its product.

Why do you think that people want to break your work? Do you really
think that making something yourself is more effective than just
reviewing someone else's work? How could it scale, if you were doing
everything yourself?

So please, please again, answer the questions Martin asked, the
questions I asked, see Rimas and Jean-Baptiste mails too. And do not
open the wiki until we all agreed on the workflow, it's really important
for our localization team.

Yes, will do, and sorry again that I haven't summarized all this before.
If you can point me to the messages I probably missed due to not being
subscribed to the l10n@ ML, that would be most appreciated.

Thank you,
Kendy

Hi Michael, :slight_smile:

So - there is no need to open the wiki for editing ever, if that is a
huge problem for people, and certainly we don't have to do this for 3.3,
and certainly we don't have to open the wiki so just anyone can turn up
from the street and spam it :slight_smile: [ it is easy to have approved
translators only eg. ]. We can provide solutions for off-line editing,
and there is certainly no need to switch tooling to make the wiki the
authoritative data source now / yesterday :slight_smile: we can do that in a
month / never if there is some insuperable problem.

Personally, I like the idea of editing the help on the wiki rather than offline.
But could the problem be solved by creating a user group on the wiki and
only allowing editing rights for that group's users? Then we could add selected
devs, i10n and docs people to that group?

Is that a feasible solution?

David Nelson

Hi Kendy,

First, thanks for your answer:

Hi Sophie,

I have heard quite some complaints about the missing native language
versions already; I am not sure I've explained it well enough
previously, but this testing is blocking it. So please - help me :slight_smile:

I've search for your explanation on our list but didn't find them.
Currently we (the localizer team) do not want the localized help to be
uploaded on the wiki until we know about the localization process that
will be in place.

I have subscribed to the l10n mailing list just on Friday, after I
learned that there were some discussions there I was not aware of until
then.

This is the list for the people doing the work you're currently removing, so you should have come first to this list :slight_smile:

Now, the explanation about wikihelp. As you may recall, the conclusion
was described as:

  create help-packs - split out the help for each language
  and simply have no help installed[1], but a web link to on-line
  help[2], and a "download your help-pack here" direction
    + not even English help would be installed -
      this will save us 11Mb in the 170Mb download

Also, each and every release notes of betas and even RC1 contained a
note "The help content is not included. We are working on the online
version. Alternatively, it will be possible to install it separately."

It is my mistake that I did not explain the exact way to implement it in
advance, I am sorry for that.

It's ok, thanks for your explanations.

So let me explain why wikihelp:

Wiki is so far the best free tool for collaboration editing I know of.
It gives anyone the freedom to improve things. With help implemented as
a wiki, any user of the suite can (potentially) just describe the
functionality better, should he/she find out that something is described
wrongly, or just partially.

We're used to work on the wiki, so yes, for documentation it's a very good tool.

Also, why should be your native language just a translation of an
English help? Should you have people that can improve the help, but
cannot speak English, why should they be bound to translating only, when
they can author the text? Why should be the French help just a
translation of an English help, when it can be an own (better?) version?

This is all the difference between documentation and the help. Creating content is much more difficult than translating it and doesn't have the same cost. So offering the help files for translation ensure that all languages have access to the same basis of *accurate* information. This is what Help is and why it should stay in a localization process. Offering the same information at the lowest cost as possible.
If it needs to be completed, lets do it as we have done until now : using links pointing to the wiki (see the Calc functions, as an example).

As I said in my mail about HC2 and localization, we use some tooling to ensure the overall quality of the files. We won't be able to use them in a wiki, it's making our work very difficult to render the same quality as the one we are currently offering. We have style guides, and several checks available on Pootle.
Just an example : we often have to correct one string in the UI, to make sure it's changed in all the files where this string is appearing, we just grep and change the string. You won't be able to do that on a wiki. Also we make large use of suggestions and comments on strings, we work off line, we use translation memory and glossaries, etc. All these tooling ensure a quality of our work that you won't be able to use on a wiki.

This is why I believe implementing the help as a wiki is the best thing
to do. How does it work:

- for 3.3, I am converting the .xhp files into wiki markup
   - it is now online as http://help.libreoffice.org
   - missing translations yet, I need to polish the tooling first
   - when the tooling is right, I'll add 2-3 more languages, for more
     testing
   - when even that approved, I'll upload the rest

- anything untranslated in the localized versions will be marked
   appropriately
   - a template for that, like {{NeedsTranslation}} + the English version

- after the import is done, and people are happy with it, it will be
   open for account creation
   - for now, please ask me directly if you want to have an account
     there, to edit pages like Main_Page, or Template:*
   - other pages might get rewritten by the import tooling

- after 3.3, I'll start to work on tooling to convert it back to offline
   help
   - to platform native help system
     - Windows/Linux/MacOSX
   - from the engineering point of view, we don't want a home-grown help
     system, as we have now
   - needs more research, to see if we don't lose features etc.

- when done, the wikihelp becomes the authoritative version of the help
   - but we'll still be able to incorporate changes from the .xhp files,
     when merging from OOo
   - we can agree that some of the localized versions would be locked for
     editing, and just taken from .xhp and .sdf files, but I _strongly_
     advise against that

Open questions:

- extended tips
   - cannot be part of the wikihelp, most probably these have to be
     handled separately, and translated using the normal process

- anything else?

We are the one doing the work and it's a very big work, so please,
answer the questions we have asked.
What if we open the git repository to anybody tomorrow?

As you might have noticed, anybody can ask for the git account, and
anybody with a bigger contribution is offered with write access.

"with bigger contribution" it is different from a wiki where anybody is able to create an account and start to work.

  will you stay
there and spend your nights correcting the bugs newcomers have done or
those not taking care of your previous work?

Oh? Were you following what we are doing on the development mailing
list? The last months, we have spent days and nights reviewing and
fixing patches from new people.

yes, provided you can discuss with this people, on a wiki, you just create a account and can stay anonymous, unfortunately. Really, all the l10n teams have spent nights on these files, we wouldn't like see them destroy by a bot.

  No, you'll go away from
such a project that do not care about your contributions and the quality
of its product.

Why do you think that people want to break your work? Do you really
think that making something yourself is more effective than just
reviewing someone else's work? How could it scale, if you were doing
everything yourself?

No you misunderstand what I say, reviewing is the same for me, but a wiki is just open to every body without knowledge of stylistic, linguistic, and so on. That can damage a lot the quality of the content. This is not a documentation, it's really different.

So please, please again, answer the questions Martin asked, the
questions I asked, see Rimas and Jean-Baptiste mails too. And do not
open the wiki until we all agreed on the workflow, it's really important
for our localization team.

Yes, will do, and sorry again that I haven't summarized all this before.
If you can point me to the messages I probably missed due to not being
subscribed to the l10n@ ML, that would be most appreciated.

Most of the time I've posted also on the dev list, so you may not have miss mine. But surely, Martin and Rimas one. I'll try to find them when I can reach the archives of the list.

Kind regards
Sophie

- after 3.3, I'll start to work on tooling to convert it back to offline
 help

Just out of interest, is there any chance that the tooling you create
can incorporate small images into the offline help or is not not
possible under the current help infrastructure?

Hi Michael,

Hi Sophie& all,

I've search for your explanation on our list but didn't find them.
Currently we (the localizer team) do not want the localized help to be
uploaded on the wiki until we know about the localization process that
will be in place.

  Well :slight_smile: this is not really for us to define; it is for the l10n team
to decide this, with us. We can give you some options of course - but it
is your call.

Ok, thanks :slight_smile:

We are the one doing the work and it's a very big work, so please,
answer the questions we have asked.

  Help us answer the questions. We are not going to impose something on
you that you don't want; and we can't make the decisions in a vacuum,
we're part of the same family - so lets try to collect requirements
together in a friendly way :slight_smile: If you have some, please knock up a wiki
page with them. Some are quite interesting, eg. the French localisation
legislation is fascinating and a new concept to me at least.

Ok this is why it's important we work together on this, we also know what is needed for our language and our users too.

So please, please again, answer the questions Martin asked, the
questions I asked, see Rimas and Jean-Baptiste mails too. And do not
open the wiki until we all agreed on the workflow, it's really important
for our localization team.

  So - there is no need to open the wiki for editing ever, if that is a
huge problem for people, and certainly we don't have to do this for 3.3,
and certainly we don't have to open the wiki so just anyone can turn up
from the street and spam it :slight_smile: [ it is easy to have approved
translators only eg. ]. We can provide solutions for off-line editing,
and there is certainly no need to switch tooling to make the wiki the
authoritative data source now / yesterday :slight_smile: we can do that in a
month / never if there is some insuperable problem.

Thanks, I'm happy to read this :slight_smile:

  Anyhow, I suspect there are perhaps three problems here, none of them
truly technical:

  A. People are paranoid about developers dictating new tools
     to them that do not meet their needs / quality
    + but this isn't going to happen
    + and hassling people providing new options is not the
      best way to have your requirements considered :slight_smile:

Yes, even if we are not against new tools or developer ideas. Localization is a hard work, with a lot of pressure because it's at the end of the process and it's a very visible work. A bad localization can ruin the developer efforts in providing good functionality.

  B. Communication is bad: lots has been written to mailing lists
     but people are either not on those lists, or unable to filter
     the signal they want from the general noise
    + This is partly because Kendy is working extremely hard
      and effectively on this, and...
    + mailing lists are the secondary developers' tool
      after IRC, and few hackers are on the l10n lists (I
      guess).

I think it's very important that developers and localizers are not so far. It's just like QA, we need to work all together. You can write the killer feature, if the localization is wrong, you're feature will never work or get the user attention it deserves. And here the Help files have a first role to play too.

  C. We didn't package Windows help packs, and communicate them
     clearly for the off-line Windows help situation [ yet ! ]
     this is getting fixed however.

great, thanks.

  Anyhow - summary - I think we don't have a big problem here - beyond
the communication issue. The answers to -all- Jean Baptiste's (good)
questions are either already answered (sometimes several times) on
various mailing lists, and/or simply not answered yet - they are open
questions. There is no need to fear the worst answer to each un-answered
question :slight_smile: hopefully together we will work out the best answer.

Silence is never good, but I hope I shout enough to be known as the one who makes the more noise in this project :wink:

  It would be -extremely- helpful if some of those most eager to know the
answers to their questions, could create a suitable wiki page, with
their questions in it - *and* preferably do a quick search of Kendy's
mails to the dev list:

http://lists.freedesktop.org/archives/libreoffice/2010-December/author.html

  Search for Jan Holesovsky in there, and collate the state of what is
there already into the page: it is not rocket science. Post the link,
and then we can work on any pending / un-answered questions.

ok, will review all this this evening

  How does that sound ?

Great, thanks a lot :slight_smile:

Kind regards
Sophie

Hi Sophie,

> I have subscribed to the l10n mailing list just on Friday, after I
> learned that there were some discussions there I was not aware of until
> then.

This is the list for the people doing the work you're currently
removing, so you should have come first to this list :slight_smile:

I hope I am not removing anyone's work; I just want to change the
workflow a bit, hopefully for better :slight_smile: And also yes, this is not set
in stone, there are several prerequisites for the last step (wikihelp
being an authoritative source for the help) that clearly depend on you -
the translators and documentation writers.

There are many technical solutions possible, including uploading the
English wikihelp pages to pootle (so far it is done per paragraph
anyway), and having chosen languages read-only in wikihelp, generated
from the English version + pootle.

> Also, why should be your native language just a translation of an
> English help? Should you have people that can improve the help, but
> cannot speak English, why should they be bound to translating only, when
> they can author the text? Why should be the French help just a
> translation of an English help, when it can be an own (better?) version?

This is all the difference between documentation and the help. Creating
content is much more difficult than translating it and doesn't have the
same cost. So offering the help files for translation ensure that all
languages have access to the same basis of *accurate* information. This
is what Help is and why it should stay in a localization process.

Maybe I am entering a thin ice here, but do not think we have a good
help as of now. There is so few information there, in many times in the
form "'Insert Picture' functionality inserts a picture from a file." :wink:

We need to grow the family of the documentation writers, and we cannot
do that by using the current tools. Authoring the .xhp files as we have
now has a terribly steep learning curve (see the description of the xml
language that is used for that, or the description of how to use the
extension for the help authoring
http://documentation.openoffice.org/online_help/helpers/helpauthoring/guide/OOo2HelpAuthoring.pdf).

So we need to do the work easier not only for the translators, but for
the help authors, or the documentation team in general, too. And I
believe that with wiki, this has the biggest potential to scale.

Offering the same information at the lowest cost as possible.
If it needs to be completed, lets do it as we have done until now :
using links pointing to the wiki (see the Calc functions, as an example).

I am sorry I haven't stressed this enough still: For 3.3, I am just
importing the help to the wikihelp, there is no change in your
processes.

Just an example : we often have to correct one string in the UI, to make
sure it's changed in all the files where this string is appearing, we
just grep and change the string. You won't be able to do that on a wiki.

It is again solvable, it is easy to provide dumps of the wiki (believe
it or not, bzipped it has only about 1.4M per language), for the offline
grepping.

Also we make large use of suggestions and comments on strings, we work
off line, we use translation memory and glossaries, etc. All these
tooling ensure a quality of our work that you won't be able to use on a
wiki.

I think the biggest issue is the offline editing; and I think here we
can use the Wiki Publisher
(http://extensions.services.openoffice.org/project/wikipublisher) to
edit the pages in LibreOffice. I did not test it yet, but if the
extension misses the functionality to merge the changes done in the
wiki, it will be easy to plug it to LibreOffice document merge feature.

> As you might have noticed, anybody can ask for the git account, and
> anybody with a bigger contribution is offered with write access.

"with bigger contribution" it is different from a wiki where anybody is
able to create an account and start to work.

It is just up to the wiki setup - we can of course have a group of
admins who will be giving rights just to the selected people, etc.

yes, provided you can discuss with this people, on a wiki, you just
create a account and can stay anonymous, unfortunately. Really, all the
l10n teams have spent nights on these files, we wouldn't like see them
destroy by a bot.

Understood - please see my other mail to JBF about fighting spam.

No you misunderstand what I say, reviewing is the same for me,

I see, OK.

but a
wiki is just open to every body without knowledge of stylistic,
linguistic, and so on.

No, it does not have to be open to everybody, even the account creation
can be restricted to selected group of people only.

Most of the time I've posted also on the dev list, so you may not have
miss mine. But surely, Martin and Rimas one. I'll try to find them when
I can reach the archives of the list.

Sorry, I missed yours, if you mean "HC2 l10n process" :frowning: The best is
to CC: me explicitly if you need the answer quickly, normally I just
scan the ML subjects quickly, read the interesting ones, and read the
rest of the messages later in batches.

Regards,
Kendy

Sure, by inspection, it is a trivial solution to this problem of
random / un-controlled user editing / spamming - notice the help is not
in the existing wiki, but a separate one anyway.

  OTOH - it seems like we have a tooling gap with the existing plan, so -
lets see where that goes. It may even be that different languages prefer
different approaches to help editing, wiki or not wiki - who knows; but
the tool is there, and (to me) looks quite cool :slight_smile: and it provides
useful search, and cross-linking for read-only on-line help today.

  ATB,

    Michael.

Hi Sophie & all,

I've search for your explanation on our list but didn't find them.
Currently we (the localizer team) do not want the localized help to be
uploaded on the wiki until we know about the localization process that
will be in place.

  Well :slight_smile: this is not really for us to define; it is for the l10n team
to decide this, with us. We can give you some options of course - but it
is your call.

We are the one doing the work and it's a very big work, so please,
answer the questions we have asked.

  Help us answer the questions. We are not going to impose something on
you that you don't want; and we can't make the decisions in a vacuum,
we're part of the same family - so lets try to collect requirements
together in a friendly way :slight_smile: If you have some, please knock up a wiki
page with them. Some are quite interesting, eg. the French localisation
legislation is fascinating and a new concept to me at least.

So please, please again, answer the questions Martin asked, the
questions I asked, see Rimas and Jean-Baptiste mails too. And do not
open the wiki until we all agreed on the workflow, it's really important
for our localization team.

  So - there is no need to open the wiki for editing ever, if that is a
huge problem for people, and certainly we don't have to do this for 3.3,
and certainly we don't have to open the wiki so just anyone can turn up
from the street and spam it :slight_smile: [ it is easy to have approved
translators only eg. ]. We can provide solutions for off-line editing,
and there is certainly no need to switch tooling to make the wiki the
authoritative data source now / yesterday :slight_smile: we can do that in a
month / never if there is some insuperable problem.

  Anyhow, I suspect there are perhaps three problems here, none of them
truly technical:

  A. People are paranoid about developers dictating new tools
     to them that do not meet their needs / quality
    + but this isn't going to happen
    + and hassling people providing new options is not the
      best way to have your requirements considered :slight_smile:

  B. Communication is bad: lots has been written to mailing lists
     but people are either not on those lists, or unable to filter
     the signal they want from the general noise
    + This is partly because Kendy is working extremely hard
      and effectively on this, and...
    + mailing lists are the secondary developers' tool
      after IRC, and few hackers are on the l10n lists (I
      guess).

  C. We didn't package Windows help packs, and communicate them
     clearly for the off-line Windows help situation [ yet ! ]
     this is getting fixed however.

  Anyhow - summary - I think we don't have a big problem here - beyond
the communication issue. The answers to -all- Jean Baptiste's (good)
questions are either already answered (sometimes several times) on
various mailing lists, and/or simply not answered yet - they are open
questions. There is no need to fear the worst answer to each un-answered
question :slight_smile: hopefully together we will work out the best answer.

  It would be -extremely- helpful if some of those most eager to know the
answers to their questions, could create a suitable wiki page, with
their questions in it - *and* preferably do a quick search of Kendy's
mails to the dev list:

http://lists.freedesktop.org/archives/libreoffice/2010-December/author.html

  Search for Jan Holesovsky in there, and collate the state of what is
there already into the page: it is not rocket science. Post the link,
and then we can work on any pending / un-answered questions.

  How does that sound ?

  Thanks,

    Michael.

I think the biggest issue is the offline editing; and I think here we
can use the Wiki Publisher
(http://extensions.services.openoffice.org/project/wikipublisher) to
edit the pages in LibreOffice.

  Ooh - that is an interesting idea :slight_smile:

  I did not test it yet, but if the
extension misses the functionality to merge the changes done in the
wiki, it will be easy to plug it to LibreOffice document merge feature.

  Sure; but I suspect there are issues around dictionaries, and other
helpful tooling that make translators lives easy :slight_smile:

  Anyhow - it'd be great to collect the ideas for flows into the wiki
page; quite possibly there are several flows possible, and we can choose
per language. eg. if there is already a near-perfect translation, I can
understand people might not want it 'vandalised' by others changing
it :slight_smile: On the other hand, if there is simply no translation at all
currently for a language, almost anything might look better than nothing
- so perhaps an in-wiki-editing policy might make sense.

  Either way, I for one am excited by the idea of having something that
is easier to edit and improve in English, although clearly the more, and
higher quality help in English we have, the harder the (already huge)
help translation problem becomes I guess.

  HTH,

    Michael.

> I think the biggest issue is the offline editing; and I think here we
> can use the Wiki Publisher
> (http://extensions.services.openoffice.org/project/wikipublisher) to
> edit the pages in LibreOffice.

        Ooh - that is an interesting idea :slight_smile:

I believe that is not a good idea. It will reformat the content and make
changes tracking a nightmare. Also, translating from changed US wiki to
other languages will be a nightmare.

> I did not test it yet, but if the
> extension misses the functionality to merge the changes done in the
> wiki, it will be easy to plug it to LibreOffice document merge feature.

        Sure; but I suspect there are issues around dictionaries, and other
helpful tooling that make translators lives easy :slight_smile:

       Anyhow - it'd be great to collect the ideas for flows into the wiki
page; quite possibly there are several flows possible, and we can choose
per language. eg. if there is already a near-perfect translation, I can
understand people might not want it 'vandalised' by others changing
it :slight_smile: On the other hand, if there is simply no translation at all
currently for a language, almost anything might look better than nothing
- so perhaps an in-wiki-editing policy might make sense.

       Either way, I for one am excited by the idea of having something
that
is easier to edit and improve in English, although clearly the more, and
higher quality help in English we have, the harder the (already huge)
help translation problem becomes I guess.

I don't have time to go to wiki and edit it, please someone do it if you
deem my thoughts worth published there.

I guess from all the discussion here we see that the LO developers and
documentation team wish to get help onto a new platform, where it will be
easier to maintain.

On the other hand the localization teams who have invested big resources
into translating the huge help system wish to continue working like before
in a Pootle or similar environment.

I propose you develop a system to have English help editable on wiki but
fully transportable back to the po/xliff system (interchangeable).
All the translations would start from the English po/xliff help files and
decide whether to
a) strictly translate English help (like we Slovenians decided) and keep
working with po/xliff files; the online help would be updated from these
files at least with every minor and major release;
or
b) develop their own help in the wiki and never go back again;

Before I go on I need an answer to a question. I tried the help in RC1 and
it seems that help items do not get passed to wiki i.e. the default module
help page opens even if you press F1 in a certain dialog (the previous
bundled help showed that definite topic in the help). Is this how the wiki
help is envisioned? If it is, one need a lot of searching to even get to a
certain topic and this makes the help totally unusable. If this is the case
the wiki help should only be a web version of the bundled help, just a copy
made after every release from the release translations.

Lp, m.

Hi Martin,

> > I think the biggest issue is the offline editing; and I think here we
> > can use the Wiki Publisher
> > (http://extensions.services.openoffice.org/project/wikipublisher) to
> > edit the pages in LibreOffice.

[...]

I believe that is not a good idea. It will reformat the content and make
changes tracking a nightmare. Also, translating from changed US wiki to
other languages will be a nightmare.

Let's see - as I said, so far I haven't done any testing, to see how
good it is; I can imagine it works just well, and of course, even the
opposite scenario :slight_smile:

I propose you develop a system to have English help editable on wiki but
fully transportable back to the po/xliff system (interchangeable).
All the translations would start from the English po/xliff help files and
decide whether to
a) strictly translate English help (like we Slovenians decided) and keep
working with po/xliff files; the online help would be updated from these
files at least with every minor and major release;
or
b) develop their own help in the wiki and never go back again;

Yes, this seems so far working for most :slight_smile: I'll make sure that all the
work you've done on the the help translation so far is not lost.

Before I go on I need an answer to a question. I tried the help in RC1 and
it seems that help items do not get passed to wiki i.e. the default module
help page opens even if you press F1 in a certain dialog (the previous
bundled help showed that definite topic in the help).

This is a blocker bug, already reported as:

https://bugs.freedesktop.org/show_bug.cgi?id=32338

It works in some of the scenarios (eg. in the menus), but not in the
dialogs. I am working on it, this is of course not intended.

Regards,
Kendy

Hi Michael,

> - after 3.3, I'll start to work on tooling to convert it back to offline
> help

Just out of interest, is there any chance that the tooling you create
can incorporate small images into the offline help or is not not
possible under the current help infrastructure?

Hard to say at the moment, without actually having started this; but of
course I'll try to retain as much information as possible - including
the images.

Regards,
Kendy

Hi Kendy, *,

Jan Holesovsky wrote (13-12-10 14:33)

Maybe I am entering a thin ice here, but do not think we have a good
help as of now. There is so few information there, in many times in the
form "'Insert Picture' functionality inserts a picture from a file." :wink:
[...]

Some parts are (very) good, some not, or just useless (as you show with the example).

We need to grow the family of the documentation writers, and we cannot
do that by using the current tools. Authoring the .xhp files as we have
[...]
So we need to do the work easier not only for the translators, but for
the help authors, or the documentation team in general, too. And I
believe that with wiki, this has the biggest potential to scale.

I think it is important and well worth trying, and from what I have seen in this thread (read a bit just this evening), there is good intention to communicate, understand the needs and work on a good solution :slight_smile:

Also this evening, I saw that others try to help us with extra tips [1] which of course is very friendly :wink:

Best,
Cor

1] http://documentation.openoffice.org/servlets/ReadMsg?list=dev&msgNo=6558