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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> > 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.

Right. I didn't pay enough attention to this.

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

No, I don't think so. There are more humans (and I think more computer
users, too) who don't have English as their first language than there
are humans (and users) who do. Said people are likely to enter more
non-English than English text. Making English the main language would
mean that each time a cell is created in a non-English language, a dummy
cell with the "English original" would also need to be created. This
seems to be a big unnecessary overhead to me.

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

Probably when going into editing mode, we should jump the cursor to the
translated cell, but there would need to be some way to show the
connections of the non-translated cell. Ugh.

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

If we use your d.trans-xx system, we'd do that by connecting a cell to
itself on the d.trans-xx for its own language.

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

If we look for translations only from the rootclone, and use your system
for translation dims, the overhead wouldn't be that big, I think. It
doesn't scale very good with the number of languages in your preflist,
though, IF the languages most of your cells are in are way down in the
preflist, because then, many failed lookups need to be made. Same if
most cells are in languages that aren't in your preflist at all.

Oh, and the language preflist should be cached in a fast access Java
structure (i.e., an array) during drawing. This would also allow having
views with different language preflists without too big a performance
problem; this would then allow intercomparison of different
translations, which would be a VERY good thing especially during
translation.

At some point we should have a compass raster or the like to show all
translations of a cell, too. (THIS would be easier with d.language and
d.language-alt, but the performance penalities are a bigger problem
indeed.)

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

That's what I thought getNLCell() to be for: from the main (=head)cell
of a vstream to be drawn, get the NL cell; draw the vstream that hangs
from that cell. I intended to do something similar with the text for my
applitude. Anything wrong with that?

- Benja