Just something I spotted in the latest translations (just forward to him / I haven't seen his name on the normal mail list either)

#: syneditstrconst.syns_attrprocessinginstr
msgid "Processing Instruction"
msgstr "Befehl ausf?hren"

should be:
Verarbeitungsanweisung

(at least that is what german wikipedia uses)

Zitat von Martin :

Mattias

Danke. Sind drin.

Mattias

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.

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

-----

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

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)

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)

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.

-----

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.

Martin

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

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

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

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

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

Stimmt.

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

DoDi

I was speaking about the list of rules on the config page. not any list of editors.

See also the wiki/help with F1 => it has additional explanations.

Don't know. they did

yep, within SynEdit,

but SourceEditor goes a step further, it kicks in, when the caret goes into the last few rows before the end (or start) of the screen. Usefull with debug-exe-line, => you keep seeing the next few lines (rather than pressing F* into the unknown, when at the bottom line of the editor)

there may be extensions, but the foundation has been layed, and I am hopeful it will not need to change.
e.g. editor locking as such does exist as featur, and will keep doing so.

But then again, if need to change is there (not talking about bugs, but talking about the idea behind the implementation) => so if anyone thinks the idea, I tried to implement is wrong and should change => then best to tell me now.

kompiliere die IDE (via tools menu) => die letzte Meldung im messages Fenster.
English: ""IDE" completed"
Deutsch: ">>IDE<< beendet"

actually t isn't >> / << but the single char quotes of that kind

Die englische Nachricht ist auch recht kurz. Aber im deutschem muesste es dann heissen: "IDE fertig" (as in Die neue IDE ist fertig)