LibreOffice WikiHelp

Hi,

I am sorry - I promised the LibO online help (WikiHelp) already the last
week, but it haven't happened; it needed more work than anticipated :frowning:

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:

Regards,
Kendy

Hi Kendy,

Hi,

I am sorry - I promised the LibO online help (WikiHelp) already the last
week, but it haven't happened; it needed more work than anticipated :frowning:

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:

Please, also coordinate this work with localizers. We have spent thousand hundreds of hours on these help files and would like to be aware of what will happen to them, and how they will be handled now, the tranlsation process and so on.
Having the help not available is currently seen as a stopper for RC1, so please, could you give us more details and explain what you're willing to do.
Thanks in advance,
Kind regards
Sophie

Have you developed processes to localize the WikiHelp?

Thanks,
Andras

Hi Kendy, :slight_smile:

Hi,

I am sorry - I promised the LibO online help (WikiHelp) already the last
week, but it haven't happened; it needed more work than anticipated :frowning:

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:

That's great... I'm sure we'll all be looking forward to seeing it. :wink:

David Nelson

Hi,

I am sorry - I promised the LibO online help (WikiHelp) already the last
week, but it haven't happened; it needed more work than anticipated :frowning:

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:

Jan,
I am looking forward to seeing this in action. As this was discussed
in the documentation conference call, the documentation team can't
wait to sink their teeth into this one.

Maybe a localisation team representative can join us on the next
documentation call to discuss their needs and you can explain how the
system will be implemented.
Clearly there can't be a different system for every language, however
as we discussed, if this were to be transitioned to the Drupal site
under development some time in the future I am sure that editorial
quality and localisation teams would be very happy with the outcome.

I would love to be able to try out some of the editing systems sooner
rather than later as we are quickly approaching launch of 3.3 with an
RC out already. Could some people on the documentation team get access
to write?

Martin Srebotnjak wrote:

Have these things been discussed and approved by the lang-teams? Or is
this the same pattern as with OOo - the big guns decide what will
happen and the lang-teams must do it their way? No matter how
inappropriate that decision is for the localizers?

There are no 'big guns' in the LibreOffice project as has been
discussed within the Steering Committee and on many other conference
calls. However there are too many localisation teams to discuss and
decide with every one regarding infrastructure, which would likely
result in duplication and un-coordinated systems.
AFAIK there is an understanding that if people are interested in 'how'
something is implemented such as documentation, websites, marketing,
etc. they join the appropriate team who makes an informed decision
while requesting input from stakeholders. It is a simple flat
structure which with collaboration between groups should work very
well, as is happening with the Drupal website that is being developed.
I can't see this being any different.

The Drupal team is working hard to ensure that no matter what language
you will be able to contribute to these core infrastructure teams when
the site is launched early next year.

Michael Wheatland

Hi Michael,

Michael Wheatland wrote (07-12-10 00:03)

Martin Srebotnjak wrote:

Have these things been discussed and approved by the lang-teams? Or is
this the same pattern as with OOo - the big guns decide what will
happen and the lang-teams must do it their way? No matter how
inappropriate that decision is for the localizers?

There are no 'big guns' in the LibreOffice project as has been
discussed within the Steering Committee and on many other conference
calls. However there are too many localisation teams to discuss and
decide with every one regarding infrastructure, which would likely
result in duplication and un-coordinated systems.

I guess Martin is referring to the fact that localisation is the hart of your international community. And there is no better way to make that part unhappy, than offering the results of their work in a way that is in-appropriate for their users/members.
(I do not yet have a judgement, I just express the existing concerns.)

Regards,
Cor

Hi,

Hi,

I am sorry - I promised the LibO online help (WikiHelp) already the last
week, but it haven't happened; it needed more work than anticipated :frowning:

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:

Jan,
I am looking forward to seeing this in action. As this was discussed
in the documentation conference call, the documentation team can't
wait to sink their teeth into this one.

Maybe a localisation team representative can join us on the next
documentation call to discuss their needs and you can explain how the
system will be implemented.
Clearly there can't be a different system for every language, however
as we discussed, if this were to be transitioned to the Drupal site
under development some time in the future I am sure that editorial
quality and localisation teams would be very happy with the outcome.

We have already our system working well since years, why do you want to change this, and even without a notice to those doing the work?

I would love to be able to try out some of the editing systems sooner
rather than later as we are quickly approaching launch of 3.3 with an
RC out already. Could some people on the documentation team get access
to write?

Please, contribute to our work, may be you will understand better our needs?

Martin Srebotnjak wrote:

Have these things been discussed and approved by the lang-teams? Or is
this the same pattern as with OOo - the big guns decide what will
happen and the lang-teams must do it their way? No matter how
inappropriate that decision is for the localizers?

There are no 'big guns' in the LibreOffice project as has been
discussed within the Steering Committee and on many other conference
calls. However there are too many localisation teams to discuss and
decide with every one regarding infrastructure, which would likely
result in duplication and un-coordinated systems.

Please, let us decide of how we are working. Again, we are not newcomers here. We take care to provide a product of very good quality since years. If you don't want to speak with us, please, do not try to provide tools and systems we don't need and want at all.

AFAIK there is an understanding that if people are interested in 'how'
something is implemented such as documentation, websites, marketing,
etc. they join the appropriate team who makes an informed decision
while requesting input from stakeholders. It is a simple flat
structure which with collaboration between groups should work very
well, as is happening with the Drupal website that is being developed.
I can't see this being any different.

The Drupal team is working hard to ensure that no matter what language
you will be able to contribute to these core infrastructure teams when
the site is launched early next year.

You will end by having people using other tools to fit their needs, that's all, I'm not sure this is what you want. Clearly, if you don't want to understand how it works, how we work, you're going to loose your time because the language groups will use their own CMS and tools and will go away from the main site.

Kind regards
Sophie

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.

Thank you a lot,
Kendy

Can someone post the IP address of that site? For me, that leads to the
old go-ooo source code documentation by doxygen. It could be a DNS
caching issue if we are trying to change the sub-domain routing.

Kohei

Ah, nevermind. The real main page is

http://help.libreoffice.org/Main_Page.

Hi Kendy, :slight_smile:

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'll be exploring it and will give you constructive feedback.

David Nelson

Hi *,

http://help.libreoffice.org is now up and running.

Can someone post the IP address of that site?

help.libreoffice.org. 86365 IN A 195.135.221.70

ciao
Christian

Hi,

I must miss something really trivial, but I do not see where to start
reading. :slight_smile: The only way to find pages from the main page is to use the
Random page or Recent changes feature.

Did I miss the point? :slight_smile:

Thanks.

Can you provide instructions for accessing the help wiki from inside
LibreOffice.

This should answer Miklos' question also.

Please, let us decide of how we are working. Again, we are not newcomers
here. We take care to provide a product of very good quality since years. If
you don't want to speak with us, please, do not try to provide tools and
systems we don't need and want at all.

I am slightly confused by this statement. Clearly there is a dialogue
going on in each functional team to achieve the best outcome possible.
This discussion is case in point.
Sophie, It seems you are feeling left out of the decision making
process. How are we able to resolve this?

Idea: The i10n team currently does not have wiki page. Could I suggest
that if the i10n team create their own page so the requirements for
native language teams can be coordinated and other projects can meet
those requirements.

You will end by having people using other tools to fit their needs, that's
all, I'm not sure this is what you want. Clearly, if you don't want to
understand how it works, how we work, you're going to loose your time
because the language groups will use their own CMS and tools and will go
away from the main site.

Sophie, it might be good for you to contribute here in a positive way
to ensure your needs are met by this fantastic new tool that Kendy has
built.
Kendy, you might be able to comment on this. But as I understand it
there is not going to be the option for language groups to break off
and create their own help wiki?

Great work so far Kendy, I can't wait to see the system working to
export the help files into the LibreOffice help. Great work!

Hi,

Please, let us decide of how we are working. Again, we are not newcomers
here. We take care to provide a product of very good quality since years. If
you don't want to speak with us, please, do not try to provide tools and
systems we don't need and want at all.

I am slightly confused by this statement. Clearly there is a dialogue
going on in each functional team to achieve the best outcome possible.
This discussion is case in point.
Sophie, It seems you are feeling left out of the decision making
process. How are we able to resolve this?

Does Kendy come to discuss the wiki idea with the l10n groups? No. Does he answer the question we asked? No. So as part of the team taking care or the help files and it's quality, yes we are left out, it's even not a question.

Idea: The i10n team currently does not have wiki page. Could I suggest
that if the i10n team create their own page so the requirements for
native language teams can be coordinated and other projects can meet
those requirements.

You will end by having people using other tools to fit their needs, that's
all, I'm not sure this is what you want. Clearly, if you don't want to
understand how it works, how we work, you're going to loose your time
because the language groups will use their own CMS and tools and will go
away from the main site.

Sophie, it might be good for you to contribute here in a positive way
to ensure your needs are met by this fantastic new tool that Kendy has
built.
Kendy, you might be able to comment on this. But as I understand it
there is not going to be the option for language groups to break off
and create their own help wiki?

The tool we work with is Pootle and we don't want a wiki or anything else. Pootle allow us to work offline which is very very important.
Pootle allow us to use our translation memory, we are able to let comment for each segment and make proposal. We have syntax rules and several checks tools available (punctuation, marks, tags, etc). We are able to ensure the quality of the file we are delivering with it. Why should we change our way of work when we are efficient and happy with it, without even asking us what we think about it. The help files are as important as the product in itself, so why should anybody be able to edit it without any idea of the process that ensure the coherence and the cohesion of it?

Kind regards
Sophie

Nobody has stated anything like "We will not be using Pootle" in fact
I know that Drupal supports the use of .po files and I am pretty sure
that Mediawiki does also.
As I mentioned before, it might be worth mentioning this first to see
if your concerns have been considered rather than jumping to
conclusions in an accusing way.

Kendy, you might be able to field these concerns further.

The tool we work with is Pootle and we don't want a wiki or anything else.
Pootle allow us to work offline which is very very important.
Pootle allow us to use our translation memory, we are able to let comment
for each segment and make proposal. We have syntax rules and several checks
tools available (punctuation, marks, tags, etc). We are able to ensure the
quality of the file we are delivering with it. Why should we change our way
of work when we are efficient and happy with it, without even asking us what
we think about it. The help files are as important as the product in itself,
so why should anybody be able to edit it without any idea of the process
that ensure the coherence and the cohesion of it?

Nobody has stated anything like "We will not be using Pootle" in fact
I know that Drupal supports the use of .po files and I am pretty sure
that Mediawiki does also.

It's not the use of .po files that is important here, it's about the tools provided by Pootle to manipulate .po and .xliff files online and offline

As I mentioned before, it might be worth mentioning this first to see
if your concerns have been considered rather than jumping to
conclusions in an accusing way.

"For now, editing features are disabled, so that we can fine tune the conversion tool. We plan to open it for your improvements with the LibreOffice 3.3 RC2. " RC2 is next week.

Kind regards
Sophie

Hi Miklos,

I must miss something really trivial, but I do not see where to start
reading. :slight_smile: The only way to find pages from the main page is to use the
Random page or Recent changes feature.

Did I miss the point? :slight_smile:

No you didn't. In fact you are spot on. If I were to put myself in the
position of a first time user of LibO and was directed to that page, I
would literally say "you gotta be joking !". What use is an online help
system in a wiki that doesn't show index links to the main topics. This
is a minimum for any help system. As for the search engine, well, I've
never been very impressed with most of the search engines used in
default wiki implementations.

The user must be given the possibility to browse through the pages of
help via links that appear, as they did in the "inline" help system of
OOo, otherwise as far as I'm concerned it is absolutely useless. If and
when the user comes across a topic for which they know the keyword to
search for, then they could of course use the search engine to enhance
their browsing experience, but IMHO you can not forego the immediate
visual need of a user. An example to look to in this case would be the
API documentation of OOo, yes, you can search for the terms using the
search engine that Collabnet provided, but you can also drill down via
links through the various API descriptions.

Whilst I appreciate that it must have taken a lot of work to get this up
onto the wiki, IMHO the visual accessibility of the information really
needs to be addressed.

Alex

Hi Kohei,

> > http://help.libreoffice.org is now up and running.
>
> Can someone post the IP address of that site? For me, that leads to the
> old go-ooo source code documentation by doxygen. It could be a DNS
> caching issue if we are trying to change the sub-domain routing.

Ah, nevermind. The real main page is

http://help.libreoffice.org/Main_Page.

How comes it is not redirected? Here it works just fine, ie. when I
type help.libreoffice.org in the browser, I get the Main_Page. I am
confused :slight_smile: - ideas appreciated.

Regards,
Kendy