[Nuxeo-localizer] New line of development

[Juan David Ibáñez Palomar]

Hi all,

Warning, this message is long.

I'd like to comment about the new line of development I'd
like to start. First let see the problem with an example.

I'm building my web site with LocalContent objects, in three
languages, french, english and spanish. The body of these
objects is usually in HTML, some have a complex strucuture,
for example with tables.

Now I'm writing the content in english, when it's finished
I'll do the translations. When doing a translation I've to
be careful to respect the format, when it's complex the task
becomes boring and it's easy to make mistakes.

The problem is, the translator shouldn't have to deal with
anything else that the content.

This is the inmediate use case I want to address. But the
underlying idea is to develop an infraestructure that lets
to reduce the costs of the management of multilingual content,
when it has structure. It could be HTML, strucutured text,
a PDF file, a Word file, etc..

The technology needed to do this is nothing new. In the Zope
world the first attempt has been made with the Base18 product,
which is inspired in the poxml tools of the KDE project. In
the internationalization industry these kind of solutions are
known as translation memory systems, being the multinational
Trados the leader in the market. Many companies, research centers
and standards are around it.


Before going further, let me say that I'll do this development
in a branch, and nothing will go to the trunk until it looks
good. So we'll have Localizer 0.9.x becoming stable towards the
1.0 version, and we'll have a development branch to try out new
ideas.


And the concrete proposed modifications are..

First, in a LocalContent object (or LocalPropertyManager), local
properties can be of two types, 'string' and 'text'. This is inspired
in the PropertyManager class, but I don't see the point anymore. So I
propose to remove the types, a local property will always be edited
with a textarea.

Second change in the LocalPropertyManager user interface. Currently
all the languages of the selected property are edited at a time. Well,
I want to change it, so only one language could be viewed and edited
at a time. Why? Right now the translation process is manual, in the
new Localizer there will be an assisted process.

And now the meet. Which will be the process?

- The content creator provides the original version of the document;

- The content creator clicks a button in the user interface, the
  action of this button is to parse the document, extract the messages
  and feed a MessageCatalog object with them;

- The translator translates the messages with the MessageCatalog
  (he won't have to deal with text formatting!);

- The content creator (or the translator) clicks another button, it
  creates a new language version for the document based on the original
  one and on the translations available in the message catalog;

- If needed the translated version can be modified.


Well, this would be only the first step. Much more work is awaiting
after it, for example, this strategy could be used to manage files,
with the right filters for each content type (PDF for instance), and
combined with LocalFolder objects to serve the data in runtime.

Well, this is the idea, comments? funding :-)?


Cheers,

--
J. David Ibáñez, http://www.j-david.net
Software Engineer / Ingénieur Logiciel / Ingeniero de Software