How do I contribute to Documentation and l10n

Hello

I am interested in contributing documentation and Hindi (India) localisation
for LibreOffice, but could not find any related information on the
LibreOffice website other than this mailing list.

Can someone please point me to a starting point ?

regards
Kinshuk

Hi Kinshuk,

I would email the website mailing list website@libreoffice.org**and ask that they set up the Hindi language in the wiki.

Ron

Hi Kinshuk and welcome :slight_smile:

Hello

I am interested in contributing documentation and Hindi (India) localisation

Concerning localization, I'll answer your other mail on the l10n list.
Concerning the documentation, we do not have a translation process yet. You can either create you own documentation in your language or translate the documentation that is available.

Next week I'll test a process that could allow us to convert and to upload the documentation files (from .ods file format) to Pootle (in .xlf file format) to be able to work with our translation tools or directly in Pootle and make the conversion back in .ods when it's over.

Kind regards
Sophie

Hi Kinshuk,
We at the documentation team have not yet decided on the tooling or
method for Documentation management. We are a very young community,
and as such just starting to develop this infrastructure.
If you wish to translate the existing English documentation into Hindi
I am sure we will be able to integrate with the infrastructure when it
has been commissioned. Our current workflow has only been established
for the English documentation, however I am personally working on a
proposal to truly internationalise the documentation development.

If you wish to put in the effort to translate the documentation into
Hindi prior to the LibreOffice 3.3 launch I would suggest downloading
the ODT of the file you want to translate, then using Google Translate
to create a first pass, very rough translation of the PDF file
available on the wiki. You could then copy the translated text back
into the English ODT file in order to maintain official formatting,
tables, images and figures, from which you could modify the text to
suit the Hindi user base.
Although there has been no official decision, I would expect that the
documentation team requires that formatting, layout, colours must
remain the same across languages (Localised fonts excepted, but if
substituted, an open font would be much preferred).

An example of using Google Translate to create a first pass is:
http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=en&tl=hi&u=http://wiki.documentfoundation.org/cgi_img_auth.php/c/c2/0101GS3-IntroducingLibO.pdf
Simply go to http://translate.google.com
Paste the web address of the PDF file into the box and press translate.

I would strongly advise against 'creating your own' documentation, as
has been suggested, as this would most likely not integrate well with
the official documentation workflow once established.

Thanks for your interest, and we are working hard to get the
infrastructure set up which properly reflects our multicultural,
multilingual community.

शुक्रिया

Michael Wheatland

Hi,

I am interested in contributing documentation and Hindi (India)
localisation

Concerning localization, I'll answer your other mail on the l10n list.
Concerning the documentation, we do not have a translation process yet. You
can either create you own documentation in your language or translate the
documentation that is available.

Next week I'll test a process that could allow us to convert and to upload
the documentation files (from .ods file format) to Pootle (in .xlf file
format) to be able to work with our translation tools or directly in Pootle
and make the conversion back in .ods when it's over.

Hi Kinshuk,
We at the documentation team have not yet decided on the tooling or
method for Documentation management. We are a very young community,
and as such just starting to develop this infrastructure.

We are not a very young community, please read again the TDF announcement, we are currently 10 years old and entering the next decade.

If you wish to translate the existing English documentation into Hindi
I am sure we will be able to integrate with the infrastructure when it
has been commissioned. Our current workflow has only been established
for the English documentation, however I am personally working on a
proposal to truly internationalise the documentation development.

Could you please stop saying non sense, it's really tiring at the end. You have no idea of what our community is, could you please respect it. Instead of again and again putting it in danger because you don't make the effort to read what is said by long community and trusted members ?

If you wish to put in the effort to translate the documentation into
Hindi prior to the LibreOffice 3.3 launch I would suggest downloading
the ODT of the file you want to translate, then using Google Translate
to create a first pass, very rough translation of the PDF file
available on the wiki. You could then copy the translated text back
into the English ODT file in order to maintain official formatting,
tables, images and figures, from which you could modify the text to
suit the Hindi user base.

Have you ever try Google translate, it's just an insult to a documentation project. Do you think our community aims this kind of quality ? I'm really afraid of what will be our site :frowning:

Although there has been no official decision, I would expect that the
documentation team requires that formatting, layout, colours must
remain the same across languages (Localised fonts excepted, but if
substituted, an open font would be much preferred).

No, of course, if you have already read what I have said, we do not request that the documentation remain the same across language. It's complete non sense and will never happen in our community. Please don't speak if you don't know.

An example of using Google Translate to create a first pass is:
http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=en&tl=hi&u=http://wiki.documentfoundation.org/cgi_img_auth.php/c/c2/0101GS3-IntroducingLibO.pdf
Simply go to http://translate.google.com
Paste the web address of the PDF file into the box and press translate.

I would strongly advise against 'creating your own' documentation, as
has been suggested, as this would most likely not integrate well with
the official documentation workflow once established.

Please stop it now, if you want to put some discredit on myself. This is 10 years that I'm building this community, so keep your wrong advise by yourself and try to respect the other that have really work for this project. Unless you want me to go away and be responsible for it?

Thanks for your interest, and we are working hard to get the
infrastructure set up which properly reflects our multicultural,
multilingual community.

Which is not true of course. You're are simply trying to say the contrary of what I say.

I'm really choked and pained by your attitude. If you want that the NL community run away, please say it now, I won't loose my time trying to build a community that you try to destroy any time you can.
This will be my last intervention, I have no time to fight for stupidities and there is a lot of place around where my time will be valued.

Sophie

Sophie,
I am sorry that you feel this way. I am not trying to undermine you, I
am simply expressing my opinion as a member of the community.
The Documentation team has had one official meeting, I was one of the
active speakers in the meeting, and very much wish to create a large
and vibrant community.
http://wiki.documentfoundation.org/Documentation/ConfCalls

I respect your experience within the community as someone who has come
along way with OpenOffice.org.
I believe that LibreOffice was formed in order for the community to
grow and improve on what has come before it, which is what David, Ron,
Kendy, Andreas, Jean (As an adviser) and myself are trying to do with
the Documentation team.

AFAIK the comments that I have made here are not in contradiction to
any decision by the documentation team. David, as the documentation
team lead, please correct me if I am wrong.

I would also appreciate a reduction in the number of personal insults.
I am new to the community, yes, however I believe I have a lot to
offer, as do many other people who have been involved with
OpenOffice.org

Michael Wheatland

Hi Michael, Sophie, Kinshuk, all, :slight_smile:

@Michael: you're quite right that the English documentation team
hasn't chosen its tools and workflow yet, and I know you're currently
working on ideas for us all to examine together. I'm looking forward
to that. :wink:

@Kinshuk: It's true that TDF and the LibreOffice project were only
recently launched *as a separate entity* from OpenOffice.org. But the
actual community *behind* LibreOffice (formerly OpenOffice.org) and
the software have existed for 10 years, and many of the people now
contributing to the LibreOffice community are veterans with many years
of experience.

With regard to NL teams: NL (native language) teams and communities
are not in any way obliged to adopt the same workflow or tools as the
English documentation team. They are totally free to decide on their
own approach to localization of the software, documentation production
and other things, too.

For instance, the libreoffice.org website is set up so that NL teams
can develop their own NL site with total independence from the English
site, as regards structure ("information architecture") and page
content.

NL teams are not at all obliged to follow a "translation-based"
approach to either documentation or their NL site. If they feel that
their particular community is better served by developing their own
content, they are free to do so.

As regards localization of the software, obviously NL teams are going
to be translating the English strings into their own language. But
there are various tools and workflows one could use for that
translation process and, here again, NL teams have total freedom of
choice: you could do it online with Pootle, or offline with OmegaT or
Poedit, or simply using an appropriate text editor, to name but *some*
of the possibilities.

For instance, in the English documentation team, we're about to start
evaluating Alfresco (I've now got a sandbox site set up, by the way,
and we can start on assessing that anytime from this week onwards).
But that doesn't impose any obligations on NL teams to follow in our
footsteps.

Of course, some NL teams might adopt a translation-based approach for
their resources (documentation, NL site, LibreOffice help, wiki
content, ...). In this case, TDF has all the facilities you need for
that, and the English docs team already has a quantity of high-quality
documentation that you can translate (we're working on producing much
more, too).

My personal experience with machine translation is that it *can* be a
time saver in certain very particular cases. But it does not work at
all well with most of the content we have to deal with. The quality of
results also varies according to the target language, and the effort
that has been put into developing the translation memory. Current
translation systems usually use a statistical approach rather than a
rule-based approach, and I can tell you with mirth and glee that human
translators are *not yet* close to being replaced by computers. :smiley:

To summarize about machine translation: it can end up giving you more
work than if you translate manually, especially if you care about
*quality*. Usually best avoided.

When you're thinking "internationalization" in the LibreOffice
community, we have a "native language" paradigm rather than a
nationality-based approach. For instance, the French NL community
services all the French-speaking countries and communities (parts of
Belgium, parts of Canada, France, various countries in Africa, ...).
For English, we service Australia, New Zealand, the UK, the US and
various other places and communities (we don't yet have the resources
to manage different varieties of English).

For India, you can well understand the reasons for this thinking.

Only in marketing are things somewhat different. Marketing is much
more country- and region-based. This is because there are notable
differences between the context in, for instance, the UK and the
context in the US. Indeed, marketing can address markets that englobe
other national/community markets - that's the case in Europe, for
example, with the EU being one marketing target in addition to the
national states it contains.

Well, that turned into quite an essay! :smiley:

HTH. :wink:

David Nelson

Hi David, all,

First of all, sorry to have loose my temper, I'm quite unused to that.

Hi Michael, Sophie, Kinshuk, all, :slight_smile:

@Michael: you're quite right that the English documentation team
hasn't chosen its tools and workflow yet, and I know you're currently
working on ideas for us all to examine together. I'm looking forward
to that. :wink:

@Kinshuk: It's true that TDF and the LibreOffice project were only
recently launched *as a separate entity* from OpenOffice.org. But the
actual community *behind* LibreOffice (formerly OpenOffice.org) and
the software have existed for 10 years, and many of the people now
contributing to the LibreOffice community are veterans with many years
of experience.

Yes, we have great localization teams, and people ready to help everywhere, without them, very few would be done. But we welcome new teams of course.

With regard to NL teams: NL (native language) teams and communities
are not in any way obliged to adopt the same workflow or tools as the
English documentation team. They are totally free to decide on their
own approach to localization of the software, documentation production
and other things, too.

For instance, the libreoffice.org website is set up so that NL teams
can develop their own NL site with total independence from the English
site, as regards structure ("information architecture") and page
content.

NL teams are not at all obliged to follow a "translation-based"
approach to either documentation or their NL site. If they feel that
their particular community is better served by developing their own
content, they are free to do so.

As regards localization of the software, obviously NL teams are going
to be translating the English strings into their own language. But
there are various tools and workflows one could use for that
translation process and, here again, NL teams have total freedom of
choice: you could do it online with Pootle, or offline with OmegaT or
Poedit, or simply using an appropriate text editor, to name but *some*
of the possibilities.

For instance, in the English documentation team, we're about to start
evaluating Alfresco (I've now got a sandbox site set up, by the way,
and we can start on assessing that anytime from this week onwards).
But that doesn't impose any obligations on NL teams to follow in our
footsteps.

Of course, some NL teams might adopt a translation-based approach for
their resources (documentation, NL site, LibreOffice help, wiki
content, ...). In this case, TDF has all the facilities you need for
that, and the English docs team already has a quantity of high-quality
documentation that you can translate (we're working on producing much
more, too).

My personal experience with machine translation is that it *can* be a
time saver in certain very particular cases. But it does not work at
all well with most of the content we have to deal with. The quality of
results also varies according to the target language, and the effort
that has been put into developing the translation memory. Current
translation systems usually use a statistical approach rather than a
rule-based approach, and I can tell you with mirth and glee that human
translators are *not yet* close to being replaced by computers. :smiley:

To summarize about machine translation: it can end up giving you more
work than if you translate manually, especially if you care about
*quality*. Usually best avoided.

When you're thinking "internationalization" in the LibreOffice
community, we have a "native language" paradigm rather than a
nationality-based approach. For instance, the French NL community
services all the French-speaking countries and communities (parts of
Belgium, parts of Canada, France, various countries in Africa, ...).
For English, we service Australia, New Zealand, the UK, the US and
various other places and communities (we don't yet have the resources
to manage different varieties of English).

For India, you can well understand the reasons for this thinking.

Only in marketing are things somewhat different. Marketing is much
more country- and region-based. This is because there are notable
differences between the context in, for instance, the UK and the
context in the US. Indeed, marketing can address markets that englobe
other national/community markets - that's the case in Europe, for
example, with the EU being one marketing target in addition to the
national states it contains.

Well, that turned into quite an essay! :smiley:

Any way, thanks for your understanding :slight_smile: This is more than 20 mails that I've tried to explain that, with no results unfortunately, so it's good to have you here, supporting my bad English, really thank you :slight_smile:

HTH. :wink:

+1 :slight_smile:

Kind regards
Sophie