[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Java and keyboard
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] Re: [zzdev] Re: [zzdev] Java and keyboard
- From: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Date: Fri, 11 Aug 2000 20:05:51 +0300 (EETDST)
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <399306BE.F5BE3BB7@xxxxxx>
> > 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?
Well, zz cells are loaded from disk lazily so just chucking out the cache
is not a problem. Also, this is not a common operation: it is no problem
if it takes something like 10 seconds...
> 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.
Sounds all right.
> 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.
Does your application really need the vstream language stuff already?
> 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
I guess the language comparison view method would be easier here.
But then the autochugging must be disabled for the headcell the language searching
is done on, or other dimensions must be used.
> > 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? ;)
i18n: internationalization. Count the characters.
> p.s. -- any thoughts on my earlier proposal for an HTML-in-ZZ structure?
I must have missed the structure part - wait, I'll have to read mail more
carefully tonight when I get on a slightly better net connection.