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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

> > Well, now I can finally demo this in Finnish, too ;) About time
> 
> By the way: What do you think about some build-in multi language
> support? I'd implement the following soon, if you think it's the right
> way to do it (or at least to experiment with):
> - headcell on d.language, if present, is a ISO two-letter code
> specifying the language of a cell's contents
> - rank on d.language-alt has translations of current cell
> - non-looping language rank on system list specifies the language
> preferences of a user: for example, I'd have "DE" -- "EN"
> - if no headcell on d.language (other than current cell), no language is
> assigned to a cell
> - new methods in ZZCell, getNLCell() and getNLText(), where getNLText()
> just does getNLCell().getText()
> - getNLCell() goes through the language pref list, and for each
> language:
> -> looks if the cell itself has this language assigned
> -> if not, looks if a cell on d.language-alt has it assigned
> -> if not, does the same for rootclone
> -> if nothing there, searches for next language on preflist
> -> if still no match, return original cell itself
> - every code that draws something on the screen should get its text from
> getNLText()
> - every code that interprets a number of cells as a text (like
> VStreamRaster) should invoke getNLCell() on the maincell of its text.

Sounds like a LOT more operations per output. Doing this for the
hundreds of cells that need to be displayed sounds like a lot of work and
potential slowdown.

A faster way would be to have a separate dimension for each language:

	d.trans-en
	d.trans-de
	d.trans-fi

etc. And we should probably fix the main language to be english, so that
the system needs to look for translations only to non-english languages.

> 
> Question to resolve: How does editing work? Before we have worked this
> out, a quick fix could be that during editing (i.e. when there's a
> cursor with an offset on a cell), drawing uses getText() instead of
> getNLText(); that way, the "real contents" of the cell would be edited.
> The *right* way to do this would be editing the translation, of course.

Right, the cursor offest's interaction with non-real text is a nasty one.
 
> I would really appreciate having this soon, so that I can do a German
> version of ZZ (of course, "magic" strings would have to be cloned; this
> would clone the magic string; the getNLCell() method would find the
> translation to put on the screen attatched to the rootclone. And the
> language pref list would allow a new level of switching between
> languages in the computer world: you just need to hop "EN" over "DE" (or
> "FI"), and you have the original English contents of a cell.

I agree that hopping cels and seeing all the labels change to a new
language would have a good hack value.

> (Note that when you translate a cell, you should also assign a language
> to the original cell, so it is easy to get that cell's contents. Ah
> well, and for translation we need of course a switch to turn automatical
> translation off, so that we can see the "real" contents of each
> translated cell.)
> 
> So, what do you think? Should I do it that way?

Let's go over some alternatives first: there is a danger of seriously
slowing down the system here. We want a solution that

1) scales as O(1) with the number of languages cells are translated in
2) works together nicely wih the cursors and offsets
3) the overhead per fetching the real text for a cell is not to much

Working with vstreams is going to be impossible this way, since inserting
a character into a cell splits it. How do you split the corresponding
cells in other languages? Sounds to me like a higher-level mechanism is
needed there.

	Tuomas