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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Fri, 11 Aug 2000, Benjamin Fallenstein wrote:

> 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?
> > 
> > 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...
> 
> Right, but we might have very big spaces. So we'd require that every
> cell is loaded anew and chugged in place? Sounds good. Which classes
> should I look at to learn about this?

No, not physically chugged. Logically chugged. The space would have
separate
CONTENT.en
CONTENT.fi
CONTENT.de
etc. files and a cell ID would probably be in the style

	15345.fi
	16324.en
	13543   # gives the user's default language

Then, d.language would be a rank which would give all the existing
language versions. Hmm, how to easily insert a new translation... Ah, 
simply by viewing in that language and editing.
 
> > > 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?
> 
> Yes, it does. I need to support German and English, and I do use
> "advanced vstreams" with variables inserted. These may be in different
> order in different languages.

Yes, but I meant: does it need the finished structural mechanism; if we
don't have that, you can still cook up something (probably something that
would be useful as a simple example for the global design).

> > > 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.
> > 
> > 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.
> 
> Right; I guess the other dimension are cleaner at this point. (Not
> dimensionS: we can use d.language without problems.) We still can use
> the same code; having different dimensions in different situations is
> not hard to do at all, after all.
> 
> Any idea how to name them?

d.cell-language
d.vstream-language
??

	Tuomas