Re: [Nuxeo-localizer] Re: New line of development

[Juan David Ibáñez Palomar]

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

The new interface of the message catalog is the first draft. The old
one gave already all it could give, and failed to manage multiline
messages. The new one looks much more like the PO editors, like KBabel,
but it still lacks all the navigation buttons.


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

Ummhh, maybe. This is certainly good for short texts.

However, when the text is long what I do is to copy and paste the
text to be translated to the textarea of the target language, and
make the translation working only with one textarea.

In the new interface the difference is that there will be a button
that will do the copy&paste, an intelligent version of the copy&paste,
because it will propose translations when posible.


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

In Gettext messages are keys, not necessarily human readable text.
However, most of the time, it's human readable text, in english,
that just needs to be translated.


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

You know that the message catalog can be exported and imported to
and from PO files. This means that translators could work offline,
something they can't do with LocalContent objects, and use PO editors
with an interface nice than the MessageCatalog one.


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

Wordfast is for Word documents, not all the content are Word documents,
fortunately.

I guess the interectation with these tools will be accomplished supporting
the TMX format, for example exporting the message catalog to TMX to feed
the translation memories.

Right now if somebody uploads a word document in english, the translator
can download it, translate it using WordFast or whatever, and upload the
new translation. This process don't involves Localizer, it can be done now
and it will be posible to do later.

But not everything are word documents, what I do with my HTML? I can't
use WordFast, I'm not going to buy a tool from a propietary software
vendor.



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

The proposed changes are to implement a simple, semi-automatic process.

But all automatic processes fail, so the user always must have the
posibility to change the document.

This is not only about the topic we're discussing, this is a general
rule. Humans say computers what they've to do, not the other way around.


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

Now that I'm on my own I expect to spend much more time on Localizer,
but the most important point is to get more resources, either human
workforce or money, and coordinate them so we don't duplicate efforts.


PS: Luis, I've seen you've sent another message, I'll read/reply later.


Best regards,

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