Re: [zzdev] Java and keyboard

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> Benjamin, does this fix fix your keyboard as well?

No, doesn't. :( And the prob exists on both Mac and Win. Lookin' forward
to testing it on Linux next week. OTOH, have never had problems with
umlauts: they're handled the right way.

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

When creating a cell, no language is assigned to it by default. (COULD
also have a param on system list to which every new cell is
automatically inserted, of course.) 

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.

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.

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