nuxeo-localizer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nuxeo-localizer] Message Catalog, user interface


From: Juan David Ibáñez Palomar
Subject: Re: [Nuxeo-localizer] Message Catalog, user interface
Date: Wed, 19 Jun 2002 00:48:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020610 Debian/1.0.0-1

Luistxo Fernandez wrote:

The need to save each message before you switch language or go to the next 
message is boring. How about...

Save this and go to: english SPANISH french

Save this and go: << (back) (forward) >>

You would also need a Cancel button, which would restore the unedited msg in 
case you have doubts about the translation you have typed...

Just personal thoughts...


It looks too much comeplex, for both the user and me (I've to implement
it ;-)

Of course the experienced user could take advantage of that. But I'm
more to keep it simple. Even graphical tools like KBabel don't provide
these features.

They didn´t consult me :-)

As you have rejected my petition, I´ll make another one. Why only one textfield 
showing only one language version at a time? Can´t we show multiple textareas 
as the *body* property of LocalContent does, with all languages shown at a time?


It isn't a definitive "no", it's just "no now, maybe next version".

The LocalContent interface had a problem. If you have for example
three languages, en, es and fr (in this order) and you want to edit
the french version, when the original is the english one, maybe you
won't be able to see both at the same time because the spanish text
area is in the middle. This problem is less sever now that it's
possible to minimize the text areas.

That is, it would be nice to have a more sophisticated interface where
the user could choose which languages to view and in which order. I
simply haven't figured out how this would be, yet.

So, for now, I prefer to stick with the simplest solution that solves
the most urgent problem.

But, if you want (or somebody else) you can try to do a mockup that
shows the desired interface, then there would be more chances that
I accept the proposal. And, of course, if somebody wants to implement
it I will be quick to give you CVS write access.


The form to add new messages would be removed, does anybody find it
useful??


seldom, but in those few occasions it has been useful for me.


Oh! I've never used it, do you remember an example??

Date related strings. I typed them into Zope code but in order to have all 
strings collected by the MessageCatalog I needed to *produce* every month page, 
or day-of-the-week combination, so the MessageCatalog could collect them all... 
it was easier to add each string manually.


In the gettext world there's a similar problem, to address it they
use defered translations. To make a dummy script would be the equivalent
here: "[ gettext(x) for x in ('Monday', 'Tuesday', ..) ]".

The PO editors don't allow to add new entries, and this is explicitly
discouraged in the gettext documentation.

I'm all for removing it now and see wether it's really needed.


You see, I'm very very obstinate ;-)

And, thank you for your feedback!!



--
J. David Ibáñez, Nuxeo.com
Libre Software zealot (http://www.fsf.org)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]