Hussein Shafie wrote:
>Benoit Maisonny wrote: > > >>Does anybody on this list have experience with dual language editing >>with XXE? How do you layout both languages? >> >>We would like to let users edit a document containing the same text in 2 >>languages and we've come up with a document structure looking like this: >> >> <Multi-lingual-block> >> <p>A paragraph in English</p> >> <p>Same paragraph in French</p> >> </Multi-lingual-block> >> >>Of course, users would like to see each p in separate column: >> >> A paragraph Same paragraph >> in English. in French. >> >>We've been playing with 3 different methods to do this with XXE and none >>of them is really satisfying: >> >>1. 2 views of the same doc >> >> > >This seems to be the approach used by professional tools for translators. > > > >>One view (i.e. style sheet) showing only EN, one showing only FR, both >>displayed simultaneously in XXE. We have a number of issues with this >>solution: >>- need for special rules to insert/delete/copy/paste in both sides at >>the right place >>- most importantly, XXE synchronises the views on the parent of the >>currently selected element, not on the element itself. This means that >>with a <div> containing several <p>, clicking inside the last <p> in one >>view will scroll the other view to the <div>, not to the (invisible) >>same <p>. >> >> > >After a bit of thinking, I think that the above approach is the most >usable one. Simply do not use "display: none;" for the language you do >not want to see, but rather use "color: #F0F0F0; font-size: x-small;" >(#F0F0F0 is a very light gray). This will make the the language you do >not want to see almost unnoticeable, but still present. And in such >case, you'll have no dual view synchronization problems. > > We would like this approach too but we find that the view synchronisation is not usable for our use case. It may be more usable for a "document structure view" use case, though. Here are the issues we found: - the element that is marked with a red corner is scrolled differently depending on its location: Upon clicking in a block inside one view, if the other view needs to automatically scroll upwards to reach that element, then the top of the element is scrolled to the top of the window, which is good. When auto-scrolling downwards, however, scrolling stops as soon as the first line of text becomes visible. I'd expect this first line to be scrolled to the top of the window, or at least that the whole block becomes visible (provided it fits the window, of course); - when scrolling one view, and without any explicit selection, the cursor follows the view: it sticks to the first line of text visible in the window. I find that this is really an annoying bug, preventing the use of shift-left button to make a long selection; - also when manually scrolling one view, the other view follows if there is no explicit selection (probably thanks to the cursor bug explained above), but not if there is an explicit selection: I think that scrolling synchronisation should be bound to what is visible, not to where the cursor is; - when another view follows my scrolling, I would like the blocks to be synchronised. The synchronisation done under Eclipse when comparing 2 files is very usable and natural: corresponding blocks in both files are always on screen at the same time (or at least the top of each block), independantly from which view is scrolled. (I know, it easier said then done, especially when XML blocks are contained in other blocks, while Eclipse compares linear blocks.) Maybe something to consider for a future version. -- Benoit Maisonny benoit at synclude.com Director & Consultant http://synclude.com Synclude
