Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Java and keyboard

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> I think I've got a way: instead of hacking getNLText-tpe stuff, we just
> define the ZZ Space to take care of it. hen we can use efficient behind-the-
> scenes operations. Then, externally each cell could be a rank on d.translation,
> with headcell of d.language being the indicated language. However, the system
> would automagically chug these into the right positions (organizing them in
> the process).

Right, this is MUCH cleaner. Only problem is efficiency when the
language preflist changes. I mean, we would have to change almost the
WHOLE zzspace every time? Any ideas on this?

> > Oh, and the language preflist should be cached in a fast access Java
> > structure (i.e., an array) during drawing. This would also allow having
> > views with different language preflists without too big a performance
> > problem; this would then allow intercomparison of different
> > translations, which would be a VERY good thing especially during
> > translation.
> 
> Hmm... my suggestion above doesn't take care of that too well, except that
> it might be possible to give different windows a different ZZSpace object..
> but that would seem a bit nasty.
> 
> Another alternative would be to explicitly allow for language seeking in the
> cellflob.

I go for that. Why don't we say that views with explicite language
seeking cannot be used for editing cell's contents? It'd be a special
case view, but there's nothing wrong with that.

We don't even need to implement it right now. But at some point, it will
be an important "thinkertoy" (esp. while translating, but occassionally
also at other times); so, we have to keep in mind such a view has to be
*possible*. (Which it is.)

> > > Working with vstreams is going to be impossible this way, since inserting
> > > a character into a cell splits it. How do you split the corresponding
> > > cells in other languages? Sounds to me like a higher-level mechanism is
> > > needed there.
> >
> > That's what I thought getNLCell() to be for: from the main (=head)cell
> > of a vstream to be drawn, get the NL cell; draw the vstream that hangs
> > from that cell. I intended to do something similar with the text for my
> > applitude. Anything wrong with that?
> 
> Ah, sorry, I guess I misunderstood that part.
> 
> Nothing wrong with this, it's only difficult to join it to the rest.
> 
> The problem is that we have two separate issues:
> - different languages for single cells, where the connections are the same
> - different, alternate *structures* for different languages - it may also
>   be that certain lists would make sense in a different order for a different
>   language. Of vial importance is something that shows that the "original"
>   has been changed and that the translation should be updated.

Yeah, but using the same mechanism for language search would be a good
thing. Problem is that your chug-in-place is not gonna work for that. At
least we could generalize the use of d.language for assigning a
language; any ideas for the rest? I very much need it, soon (next few
weeks) -- but my mind blanks.

It would be nice if we could find a way so that another structure could
be chugged in place, but I have no idea as to how. Or we might want to
use a similar system as for the language seeking in language comparison
views.

> This is a tough one. And a very important one, too. It will be good to have
> i18n at such an early stage.

Was that just meant to read "have it in," or something more
sophisticated? ;)

- Benja

p.s. -- any thoughts on my earlier proposal for an HTML-in-ZZ structure?