Internationalization

Hi all,

I would like to just add some thoughts about internationalization (i18n is shorter) of the documentation.

Some native-lang groups will produce its own documentation, some others will translate what is available in en_US language or other languages, and sometime it will be both.

For the FR project, I'm currently testing some tools for the translation of the OOoAuthors Guides.

Translating on the wiki is horrible, I've translated two guides and they are now completely obsolete and not in sync with the rest so it's a waste of time finally.

With the .odt files we can use translating tools, glossaries and translation memory. I'm testing WordForge as the local translation tool currently (it manages odt -> xliff -> odt), and I think also to use Pootle to organize the workflow (you can assign roles and tasks, you know the amount of work is remaining, it's easy to check for errors like missing translation, double punctuation or missing caps, extra space, etc, you can work on line or off line and it handles xliff files).

Would you be interested by this workflow at an i18n level, or do I go on only with the FR group here? This question because it needs more testing (will do after the 3.3 is out), and some styles (the low level ones it seems) will have to be adapted in the .odt file for conversion purpose to .xlf files. So it might be interesting to adapt it to your current workflow and requirements too.

Kind regards
Sophie

Hi Sophie, :slight_smile:

Hi all,

I would like to just add some thoughts about internationalization (i18n is
shorter) of the documentation.

Some native-lang groups will produce its own documentation, some others will
translate what is available in en_US language or other languages, and
sometime it will be both.

For the FR project, I'm currently testing some tools for the translation of
the OOoAuthors Guides.

Translating on the wiki is horrible, I've translated two guides and they are
now completely obsolete and not in sync with the rest so it's a waste of
time finally.

With the .odt files we can use translating tools, glossaries and translation
memory. I'm testing WordForge as the local translation tool currently (it
manages odt -> xliff -> odt), and I think also to use Pootle to organize the
workflow (you can assign roles and tasks, you know the amount of work is
remaining, it's easy to check for errors like missing translation, double
punctuation or missing caps, extra space, etc, you can work on line or off
line and it handles xliff files).

Would you be interested by this workflow at an i18n level, or do I go on
only with the FR group here? This question because it needs more testing
(will do after the 3.3 is out), and some styles (the low level ones it
seems) will have to be adapted in the .odt file for conversion purpose to
.xlf files. So it might be interesting to adapt it to your current workflow
and requirements too.

My 2 cents would be that it would be good to keep us posted. At the
present time, there is not too much consensus on workflow yet in the
documentation project... We're working on it, though. About the only
thing that regular contributors seem to agree about ATM is that
ODF/ODT is the best central format, with other formats for end users
being generated from ODT.

I'm not too sure precisely how we can work i18n into our own
workflow... If you have specific suggestions then I'd be interested to
hear.

One package I'm currently interested in is Alfresco... I plan to
experiment with it between Christmas and New Year... Maybe there is a
possibility with this tool that we *could* design a more integrated
workflow with interested i18n teams... But this is pure conjecture for
the moment - I need to see it working first.

David Nelson

Hi David,

Hi Sophie, :slight_smile:

Hi all,

I would like to just add some thoughts about internationalization (i18n is
shorter) of the documentation.

Some native-lang groups will produce its own documentation, some others will
translate what is available in en_US language or other languages, and
sometime it will be both.

For the FR project, I'm currently testing some tools for the translation of
the OOoAuthors Guides.

Translating on the wiki is horrible, I've translated two guides and they are
now completely obsolete and not in sync with the rest so it's a waste of
time finally.

With the .odt files we can use translating tools, glossaries and translation
memory. I'm testing WordForge as the local translation tool currently (it
manages odt -> xliff -> odt), and I think also to use Pootle to organize the
workflow (you can assign roles and tasks, you know the amount of work is
remaining, it's easy to check for errors like missing translation, double
punctuation or missing caps, extra space, etc, you can work on line or off
line and it handles xliff files).

Would you be interested by this workflow at an i18n level, or do I go on
only with the FR group here? This question because it needs more testing
(will do after the 3.3 is out), and some styles (the low level ones it
seems) will have to be adapted in the .odt file for conversion purpose to
.xlf files. So it might be interesting to adapt it to your current workflow
and requirements too.

My 2 cents would be that it would be good to keep us posted. At the
present time, there is not too much consensus on workflow yet in the
documentation project... We're working on it, though. About the only
thing that regular contributors seem to agree about ATM is that
ODF/ODT is the best central format, with other formats for end users
being generated from ODT.

I'm not too sure precisely how we can work i18n into our own
workflow... If you have specific suggestions then I'd be interested to
hear.

One package I'm currently interested in is Alfresco... I plan to
experiment with it between Christmas and New Year... Maybe there is a
possibility with this tool that we *could* design a more integrated
workflow with interested i18n teams... But this is pure conjecture for
the moment - I need to see it working first.

Ok, so I go on on my side and will come back later with a documented process for those who want to use it.
I've used Alfresco at my work latst year, it is a great tool to manage files. You'll need a plugin to work within LibO
http://forge.alfresco.com/projects/ooo-plugin/

Kind regards
Sophie

Hi Sophie, :slight_smile:

Ok, so I go on on my side and will come back later with a documented process
for those who want to use it.
I've used Alfresco at my work latst year, it  is a great tool to manage
files. You'll need a plugin to work within LibO
http://forge.alfresco.com/projects/ooo-plugin/

So do you see any potential for some i18n/US docs integration for
interested teams?

David Nelson

I mentioned it before, but I think it is worth stating again, the
integration between Alfresco and the planned Drupal tooling should be
very straight forward as there has been a lot of coordination between
the projects. If we are looking at Alfresco seriously it could also be
used to automatically publish the finished documents once approved on
the Drupal site.

I am very interested in hearing how it copes with internationalisation
of documents and handling revisions and change approvals across
languages.

Hi David,

Hi Sophie, :slight_smile:

Ok, so I go on on my side and will come back later with a documented process
for those who want to use it.
I've used Alfresco at my work latst year, it is a great tool to manage
files. You'll need a plugin to work within LibO
http://forge.alfresco.com/projects/ooo-plugin/

So do you see any potential for some i18n/US docs integration for
interested teams?

Alfresco doesn't handle xliff files and doesn't propose any l10n services. So it mays not serve for i18n or only to publish the final .odt conversion once the work done.

Kind regards
Sophie

Hi Sophie, :slight_smile:

Alfresco doesn't handle xliff files and doesn't propose any l10n services.
So it mays not serve for i18n or only to publish the final .odt conversion
once the work done.

So as someone who has used it before, what would your comments be on
Alfresco as a tool for the US English documentation team?

David Nelson

Yes I think so, it's easy to use and should cover almost all your needs.
I, for myself, prefer version control systems (bad habit, even working with Eyrolles, my publisher, I do not use CMS here ;), but that might be to technical for authors.
At least, if I remember well, that was one of the reasons, Jean and her team didn't like the OOo workflow and settled OOoAuthors, where people like Alex or me did like it.
So Alfresco should definitely be better for the en_US workflow.

Kind regards
Sophie

Hello Sophie,

Thanks for your input on i18n issues

Op 17/12/2010 8:10, Sophie Gautier schreef:

Hi all,

I would like to just add some thoughts about internationalization (i18n is shorter) of the documentation.

Some native-lang groups will produce its own documentation, some others will translate what is available in en_US language or other languages, and sometime it will be both.

For the FR project, I'm currently testing some tools for the translation of the OOoAuthors Guides.

Translating on the wiki is horrible, I've translated two guides and they are now completely obsolete and not in sync with the rest so it's a waste of time finally.

Fully agree

With the .odt files we can use translating tools, glossaries and translation memory. I'm testing WordForge as the local translation tool currently (it manages odt -> xliff -> odt), and I think also to use Pootle to organize the workflow (you can assign roles and tasks, you know the amount of work is remaining, it's easy to check for errors like missing translation, double punctuation or missing caps, extra space, etc, you can work on line or off line and it handles xliff files).

I would love to use translating tools, as for now, we have not used any in the Dutch speaking team

Would you be interested by this workflow at an i18n level, or do I go on only with the FR group here? This question because it needs more testing (will do after the 3.3 is out), and some styles (the low level ones it seems) will have to be adapted in the .odt file for conversion purpose to .xlf files. So it might be interesting to adapt it to your current workflow and requirements too.

Please keep us updated on your progress, we will give feedback from Dutch team

Kind regards
Sophie

Best regards

I have had a bit of a brainstorm here. It will take a few days to put
together the idea proposal so people understand it, but I should have
it out by boxing day. It deals with documentation development across
languages, feeding back into an approval system per language.

Mike Wheatland

Hi, :slight_smile:

I have had a bit of a brainstorm here. It will take a few days to put
together the idea proposal so people understand it, but I should have
it out by boxing day. It deals with documentation development across
languages, feeding back into an approval system per language.

That will be interesting to read. But, hopefully, it will be
concretely implementable in a fairly short time. Also, it might want
to take the following into consideration:

Sophie explained to me that, typically, in Open Source projects,
English is usually the "root" language for development and all other
processes around the core development, and that localization tends to
simply be a process of translating all that has been produced in
English.

But, she explained, in LibreOffice, there is a drive towards giving
each NL project independence in producing its own content, in the form
it thinks is best - even though an English version of a content may be
offered as a possible working base, if the NL project wants to adopt a
"translation-based" approach rather than an "own-creation" approach.

You can see this in the SilverStripe website, on which each NL project
gets a sub-site that it's free to structure and people with content as
it sees fit. For example, the French or German NL projects are not in
any way obliged to have a site structure that is a "clone" of the
English structure. They might adopt a quite different IA for
communicating with their user base and servicing its needs.

(I must say that I rather like these ideas.)

So we'd be looking for a system that caters to this autonomy.

HTH.

P.S. When we're talking about NL, we're talking about *languages* not
"national/political" boundaries.

David Nelson

I don't want to go into too much detail until the proposal has been
developed fully, as it may give people the wrong idea, as has happened
here before, but let me assure you that this idea is based solely on
that idea whilst maintaining the benefits of the workflow that Jean
proposed early on in the process for the English documents.

Hi Michael, :slight_smile:

I don't want to go into too much detail until the proposal has been
developed fully, as it may give people the wrong idea, as has happened
here before, but let me assure you that this idea is based solely on
that idea whilst maintaining the benefits of the workflow that Jean
proposed early on in the process for the English documents.

That's great. I'll be looking forward to reading it, as I'm sure we
all will, and will give constructive feedback.

David Nelson

This applies to localization and documentation, while marketing is by geography, as it doesn't make sense - for instance - to put together Spain with Mexico, or US and UK.

Hi Leo,

Hello Sophie,

Thanks for your input on i18n issues

Op 17/12/2010 8:10, Sophie Gautier schreef:

Hi all,

I would like to just add some thoughts about internationalization
(i18n is shorter) of the documentation.

Some native-lang groups will produce its own documentation, some
others will translate what is available in en_US language or other
languages, and sometime it will be both.

For the FR project, I'm currently testing some tools for the
translation of the OOoAuthors Guides.

Translating on the wiki is horrible, I've translated two guides and
they are now completely obsolete and not in sync with the rest so it's
a waste of time finally.

Fully agree

With the .odt files we can use translating tools, glossaries and
translation memory. I'm testing WordForge as the local translation
tool currently (it manages odt -> xliff -> odt), and I think also to
use Pootle to organize the workflow (you can assign roles and tasks,
you know the amount of work is remaining, it's easy to check for
errors like missing translation, double punctuation or missing caps,
extra space, etc, you can work on line or off line and it handles
xliff files).

I would love to use translating tools, as for now, we have not used any
in the Dutch speaking team

Yes and I really would like to be able to provide something that ease the work in the 3 languages at an equal level, so it would be easier to provide some "official" documentation as it was requested by some Belgian administrations.

Would you be interested by this workflow at an i18n level, or do I go
on only with the FR group here? This question because it needs more
testing (will do after the 3.3 is out), and some styles (the low level
ones it seems) will have to be adapted in the .odt file for conversion
purpose to .xlf files. So it might be interesting to adapt it to your
current workflow and requirements too.

Please keep us updated on your progress, we will give feedback from
Dutch team

Thank you for your support. I'll work on this next week and keep you update.

Kind regards
Sophie