> Are you using XMLEditor 5.3.0. I remember, Gunnar and I had trouble due to a different version.

You should upgrade if nothing because otherwise you will create a *lot* of changes on Bean Validation's spec if you use it.

> sure, different tooling might be a solution. I am still a little sceptical about Asciidoc, but happy to try. Are there already maven
plugins to convert from asciidoc to docbook? Or would we try to go directly from asciidoc to html/pdf? I guess that would cause problems with the gettext translation system

There is a plugin https://github.com/asciidoctor/asciidoctor-maven-plugin

>> not to do text wrap and do say one sentence per line.

> -1 that seems wrong. I think the test should read as close as possible to "normal" text/prosa. One sentence per line is something for poems, but not for regular text. I guess we could have some some set line length and break around that.

The problem with text wrapping after specific line length will bring us back to a lesser degree in the problem we are already facing. If I change the second line, fourth and twenties line of a paragraph, the source diff will show line 2 to line 24 as changed and reading it as source diff will be hard. Granted we could use the final output but when applying a lot of different changes (like back porting), this becomes very slow and cumbersome. So ideally, we should find a solution that does not create such source diff noise. The options (in modern markups) are:

1. one line break every nth chars (with he problems described)
2. one sentence per line (with the occasional weirdness of non WISIWIG brain rendering)
3. one paragraph per line (which is harder to use as depending on the text editor you need scrolling or harder to use navigations and diffs become less readable too)
4. arbitrary line break based on human decision (which has some of the problems in the hard rule around line break and potential for guerrilla fights between commits

2 and 4 are the most viable options imo.