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

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> I meant with caching the last accessed language. (I.e., using the old
> model inside the DimCells and save the last accessed contents in it;
> when the same language is accessed again, the cached contents are used.)

That requires testing the language. I'd prefer saving the null language
inside the cells and for non-null languages, use hashtables in the ZZSpace
object.
 
> > In such case, I'd suggest starting a new CVS branch if there's a major
> > change that touches the core. That way the change can be discussed and
> > developed before it affects any other code.
> 
> I can see reason in that. :) I'll remember to do so next time.

Thanks.

> > I mean, I'd like a model where there's a "Default text" and then "language
> > text", and default text is fast to access.
> > 
> > I *don't* like
> > 
> >         a.getText()
> > 
> > being redirected to
> > 
> >         a.getText("en")
> > 
> > at all.
> > 
> > In my spaces, I will be liberally mixing Finnish and English and possibly
> > want to be translating either to either later.
> 
> Yeah, you've definitely learned a lot since. You wanted English to be
> the default language. ;o)

;)
 
> A possibility would be to have the not-assigned mode a.getText(null),
> but to redirect a.getText() to "en". (side note: I think of a.getText()
> as "get system-readable contents", b/c everything else would *truly*
> need a lot of changes in the code.)

Yes, that sounds about right. System-readable and default, and
getText(lang) is translation.
 
> Urgh, just realized: but numbers don't have a language! Yuck. So maybe
> system == no language assigned isn't SO bad. But "CellViews" is still
> very definitely English...
> 
> Or maybe we define the a.getText(null) as "Computercode." :-}

Just like the "C" locale - not bad. But as a matter of aesthetics, I'd
like a.getText(null) to be redirected to a.getText() which would work
exactly the old way. That would make

	a.getText("fr")

for example equivalent to asking "does there happen to be a french
translation of this cell? If not, just give me the default content".

This is what I meant by the two parallel systems, and how you can do this
without causing any performance degradation (except a little .class file
size increase) to people who don't use it.
 
> > One thing I also don't like at all is that *all* things that paint text to
> > the screen now have to take into account the language, if they want to be
> > i18nable.
> > 
> > Java doesn't let us do it but having a language context in the window
> > would be far better, so that simple getText() would always return the
> > right thing for each window. That would be ideal.
> 
> Um, but what about the reads which want to get "code" -- like "true,"
> "CellViews," etc.? -- We'd have that problem with different ZZSpace
> objects, too, wouldn't we? (Or maybe we'd have a getText() and a getCode()?)

getText() and getUserText()?

> Yeah, it's not nice that everything has to think about the language...
> we could have a.getText(window cell), although basicly ZZCell is not the
> place to put things which are that specific.

ZZI18N.getText(cell, window cell)? This way there would actually have been
no need to alter anything except display routines, which would be very
good in a different way.

But do we know the window cell in all the right places?

One small problem, BTW: two windows in different languages next to each
other, and inserting text into one of the languages. The insertion cursor
will look silly, and possibly even cause out-of-string-bounds exceptions
on the other side.

	Tuomas