Re: [zzdev] Re: Two hashtables per cell? No way!

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Hi Tuomas --

OK, let's get this straight. What *exactly* do you want?

I think I understood:
1) only one CONTENT file
2) ZZCell.getText() returns what's in that CONTENT file
3) i.e. the core changes I made are changed back
4) a ZZLanguage -- no, we'll use it a lot, let's call it Lang -- object
will take care of finding the right text, and of writing text in the
right place
5) the view building method reads a Language param of the window cell,
like the View and CellView params, probably as a ZOb; if none is set,
DefaultLang is used, which just calls getText() / setText().

What I haven't understood yet: how should the Lang object be stored/passed:
a) as a parameter to be passed?
b) in a static variable which is synchronized when building views --
i.e. Lang has a public static Lang currlang; (or so) which the rastering
method sets and synchronizes, and the cell views etc. just read that one?

The latter wouldn't be so bad, as our current system builds views one
after another anyway. But then, what about key presses during view
building? Should we just wait until view building is finished? Or should
we have a seperate static Lang object for them?

And: how are the languages stored in the structure:
i) on d.language/d.language-alt?
ii) on d.content-en, d.content-de, d.content-fi, d.content-fr ... ?
iii) in some other scheme?

And: should I revert back the changes that pass the window cell to the
cell views? (If not, I'll have to make them everywhere, so that we can
get rid of the old way to call them.)

( i) is easier to view, but ii) might be faster to access -- i) is very
wasteful in terms of space, too -- or we could have d.language-alt as a
dim the system deducts, like d.cellcreation and the slice dims. or we
could have a compass raster only showing dimensions starting with
"d.content-"... )

If possible, please reply quickly, so I can implement. Thx,
- Benja

Tuomas Lukka wrote:
> 
> > ... or what about a ZZLanguage object, which is passed and has a String
> > read(ZZCell) method, which <everything that draws text on the screen> is
> > supposed to use?
> >
> > This'd implement language preflists and the like. (Would also have a
> > write() method for ZZPrimitiveActions etc. And it could be somehow
> > associated with the window cell and retrieved through it?)
> >
> > Not perfect either, of course...
> 
> Much nicer, and actually it doesn't need ANY changes to the original core.
> I came up with about the same (except statically) in the previous message,
> I guess this could be even better.
> 
> I like it, it's minimal resistance.
> 
> VStreams will be more difficult, again, but we'll see about those later.
> Maybe they actually don't need direct I18N but more explicit stuff...
> 
> So this would be in the place where the Raster and the CellView are
> created, and there you'd do setLanguage(ZZLanguage.getLanguage(window));
> And have ZZDefaultLanguage object which just calls getText() - small price
> to pay, and then another with a preflet list which would read the
> structure more deeply.
> 
> Now all the multilingual versions could be stored in the structure which
> would also help since you can then rotate to a view that shows all
> translations.
> 
>         Tuomass