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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

> > 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().
> 
> Not necessarily a ZOb: the
> 
>         ZZLanguage.getLanguage(ZZCell c)
> 
> can see along d.lang-prefs whether there is anything: if nothing, return a
> ZZDefaultLanguage object, otherwise the ZZPrefLanguage object.

Yes, but if we use the same structure as with views and cell views,
users can rotate through different language prefs like through the
views, instead of introducing some other, new way to handle stuff.

So when you have edited in Default, and now want to translate to
Finnish, you rotate to a language view which shows Finnish if available,
and Default if not, and which changes to view Finnish when you enter
text. When you're done with that, you rotate to a language view which
shows Default if available, and searches the other languages if not...
well, you get my point.

By the way, I'd say we should call the whole thing a "Texter," because
it's useful beyond the scope of languages: e.g., you could have a texter
which shows the content of a cursor's accursed cell in the cursor cargo
cell -- that's something I'd like to have in the Flowing Clang
structural debugger (when viewing the stack frames).

> > 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?
> 
> I'd say a): get it in ZZDefaultSpace.getScene and pass it to the views.

Will do.

> > 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?
> 
> My preference would be for d.translations, as then you'd see the whole
> rank of the translations in all languages easily.
> 
> But that's not yet a strong point; if you can think of any for the other
> systems, do tell.

Well, how would we assign languages to cells? What I can think of is
having a separate cell on d.language denoting the language -- but that
would, as I said, be quite wasteful in space.

(We do not want to have it in the cell ids, so that we can assign a
different language when we entered something else than the system
expected. This'd be totally easy with ii). Plus, if I edit something in
German, but in no other language, including default, it would make sense
to have default show that; with i) and ii) as proposed that would work,
with different cell IDs, it wouldn't.)

> > 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.)
> 
> Where is that change?

In myCellView.makeFlob(...), the window cell is given now; it didn't use
to be passed on. Obviously, this means every view which uses the cell
view given to it to place flobs needs to be updated to the new calling convention.

> > ( 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-"... )
> 
> Why is i) wasteful in space?

See above.

> But ii) is a good alternative, too.

So, my points said, which one do you want?
-b.