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

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

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

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

Yes, A-J told me. Made me think of v13n :)

- Benja