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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

> > > Question to resolve: How does editing work? Before we have worked this
> > > out, a quick fix could be that during editing (i.e. when there's a
> > > cursor with an offset on a cell), drawing uses getText() instead of
> > > getNLText(); that way, the "real contents" of the cell would be edited.
> > > The *right* way to do this would be editing the translation, of course.
> > 
> > Right, the cursor offest's interaction with non-real text is a nasty one.
> 
> Probably when going into editing mode, we should jump the cursor to the
> translated cell, but there would need to be some way to show the
> connections of the non-translated cell. Ugh.

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

> > > So, what do you think? Should I do it that way?
> > 
> > Let's go over some alternatives first: there is a danger of seriously
> > slowing down the system here. We want a solution that
> > 
> > 1) scales as O(1) with the number of languages cells are translated in
> > 2) works together nicely wih the cursors and offsets
> > 3) the overhead per fetching the real text for a cell is not to much
> 
> If we look for translations only from the rootclone, and use your system
> for translation dims, the overhead wouldn't be that big, I think. It
> doesn't scale very good with the number of languages in your preflist,
> though, IF the languages most of your cells are in are way down in the
> preflist, because then, many failed lookups need to be made. Same if
> most cells are in languages that aren't in your preflist at all.

However, that's not *terribly* likely.

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

> At some point we should have a compass raster or the like to show all
> translations of a cell, too. (THIS would be easier with d.language and
> d.language-alt, but the performance penalities are a bigger problem
> indeed.)

Right. OTOH, that's not a common operation.

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

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

	Tuomas