[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] Java and keyboard
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] Java and keyboard
- From: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Date: Tue, 8 Aug 2000 18:11:41 +0300 (EETDST)
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3990060B.CA878265@xxxxxx>
> > > 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
> > > 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
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
> 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
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.