[Nuxeo-localizer] Re: New line of development

[Luistxo Fernandez]

J. David:

>
>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.

I would say that there´s one leading standard: TMX (http://www.lisa.org/tmx/)

>
>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.

Does this mean that it will look more like the new interface of the 
MessageCatalog? I am a little bit suspicious about it. Plainly, I don´t like 
the new interface.

Why not two languages in parallel? Translation is essentially a 2-language 
issue.

I am not that familiar with software development and maybe my words sound 
strange (cause I may be wrong, of course). For instance, I just don´t 
understand too well the logic behind .po files. The .po format is essentially 
monolingual which doesn´t make much sense. You have a msgid and probably the 
text there is in english or some original language, and you use the msgstr to 
provide the translation...

>
>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!);

But he will have to deal with Zope´s and Localizer´s MC interface?
That´s not realistic, I´m afraid. Not even good or desirable.

Translators work with their computers, with a personal memory, or a shared 
memory in an translation unit or company. They access that memory through 
Trados or Star Transit or Wordfast (a very interesting free-of-charge tool, not 
free software: http://champollion.net/ ).

You don´t have to provide him a new interface. He has his software, his 
interface, his training and his memories ready.

>
> - 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.

How? That´s an interesting point. Original content is one step, but content 
updating in various languages... I have my own vision. I´ll try in another 
message.

>
>
>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 :-)?

This new line is truly important for the future of Localizer, no doubt. David 
has thought quite a lot about it, it´s clear. We at Code & Syntax 
(http://www.codesyntax.com) have also our thoughts, and hope to discuss about 
this.

In september a customer of us (a university research department) will open a 
new online tool created by us. It´s a management tool for bilingual 
document-handling: its purpose is to catalogue the whole standard set of 
documents of the organisation, and store them in the web in the form of 
editable, searchable documents, with options for bilingual parallel vision and 
downloading of TMX memories generated automatically.

In october, another customer of us will open its redesigned website. It´s the 
Basque Translators´ Association. Nothing special about that project, except 
that it will be a multilingual website. Its an interesting customer for us: 
they came to us because they know we make decent multilingual sites (using Zope 
and Localizer), and although they have no one familiar with Zope now among 
them, I think that some of them will inmerse in this tool with interest, and 
provide good ideas and real usage cases from real translators.

So, we have interesting projects ahead. Workflow and TMX are involved in them. 
This new line of development proposal comes at a perfect timing.

Luistxo