[Lazarus] Lazarus-Übersetzung, Ergänzungen

[Hans-Peter Diettrich]

Martin schrieb:

> A few remarks, including the english choice of wording. (which may 
> itself be not ideal)
> 
> "Pages and Window"
> 
> Contains settings for the notebook-tabs, and multi-editor related stuff. 
> On the first look it should then be called "Tabs and multi-editor", but:
> - the word editor is already the caption of the parent node. So all the 
> nodes in the editor section are about editors. (initially it was called 
> "multi window")
> - tabs (in english)  can be confused with the tab key (#09)
> 
> So I ended up with "Pages" to represent notebook tabs; and "windows" to 
> indicate multi-editor)
> Any better idea is welcome.

My view on the editor is like this:

An editor window holds an (tabbed) edit book with pages (SynEdits).
A multi-window editor can have open any number of edit books.

I'm not sure about the best English representation, e.g. edit-books, 
editor books?
Some native speaker should jump in...

> -----
> About the german translation:
> 
> 1) Editoren mit selben Kriterien, => die 2te uebersetzung ist 
> fehlerhaft. Im englischem heisst es "zuletzt fokussiertem Fenster" 
> (Fenster fehlt derzeit in der Uebersetzung)
> 2) "Kriterien nach denen ein Editor gewaehlt wird" muesste sein 
> "Prioritisierte Kriterien-liste, nach denen ...."
> The list is evaluated top-down (entries are ordered by priority)
?
The list is ordered, with the most recently used page/window(?) at the 
begin(?)

The implementation may change, multiple edit windows still are 
experimental. I'd not go into details here.

> -----
> 
> "in view" versus "in centered view"
> 
> The english choice of description is already bad, and better suggestions 
> are welcome.
> 
> The background:
> In the past many function that set the cursor (current debug line, jump 
> to bookmark, jump to...) have in the past *always* set the cursor to the 
> *exact* center of the screen.

Why that? :-(

> As a result the editor always would scroll, even if the line was well 
> within the visible area. That is irritating if you jump between 2 points 
> that are both visible. Or in debugging, pressing F8 would always scroll 
> (which again according to feedback I had, was seen as irritating)

+1


> The new concept (still work in progress), is to define an area of the 
> screen as acceptable centered area. (depending on the height of the 
> editor, between 2 and 8 lines from top/bottom), and avoid scrolling, if 
> the jump-target-location  is in this area. ( locked-editors can use the 
> full visible are, as they will not scroll, even if your jump target is 
> right on the first (or last) visible line)

I remember a ScrollIntoView method, that can (should?) do nothing when 
the caret already is in the visible part of the text.


> An unlocked editor should only be choosen, if the jump-target is in this 
> area, because this means it will not need to scroll (not always true 
> yet, work in progress)
> 
> Again, better naming is welcome.

Again, we IMO should wait for a final implementation, before describing 
technical details.


> -----
> 
> I have updated some of the english descriptions, after reading the 
> german translations.
> 
> ------
> unrelated
> 
> In der deutschen Uebersetzung ist die Meldung fuer das erfolgreiche 
> Kompilieren der IDE: ">>IDE<< beendet"
> 
> Sollte besser "IDE kompilieren beendet" sein? Schliesslich ist die IDE 
> selber ja nicht beendet.

Stimmt.

BTW, which text and translation are we talking about? ;-)

DoDi