#314 Separate paragraphs in Editor

[Jean-Christophe Helary]

With rules based segmentation it is not clear if a segment is independant or if it originally belonged to a bigger set, like a paragraph.

Depending on the segment status (set member or independant) translation may vary (verbal mode etc).

It is thus important to have an indication of whether a segment is contextually connected to the preceding one.

A possibility would be to have "original" segments (ie segments existing before rules have been applied) displayed the standard way:

<segment nn>mnmnmn<end segment>

and to use a different representation for "subsegments" like:

<segment nn>mkmkmkmk[end subsegment]
[segment nn+1]wewewewewew[end subsegment]
[segment nn+2]efefefeefefefefe[end subsegment]
[segment nn+3]wewewewewew<end segment>

That way it is much easier to get the full context _and_ to understand why tags don't behave like they should (although that is discussed in the documentation, it is not always clear).

Since parsing of "inline" strings (like alt contents etc) seems to happen at the same stage as the "paragraph" parsing, I don't see how to clearly visually identify such string, but it seems to me that is important too.

[Jean-Christophe Helary]

Logged In: YES
user_id=915082
Originator: YES

I am thinking, what about keeping the original segment structure and putting "static" subsegment tags in it ? The whole thing would look like a tagged segment but would be a number of subsegments visually grouped together. Like:

<segment nn>mkmkmkmk[nn+1]wewewewewew[nn+2]efefefeefefefefe[nn+3]wewewewewew<end segment>

of course, operation would be exctly as it is now. only the "sub" part that is entered is editable, all the rest is only clickable. _OR_ only the segment marks are not editable and the rest is freely editable... That would make seegmentation problems much less of an issue, while keeping all the extra power segmentation adds to the process.

[Samuel Murray]

Logged In: YES
user_id=168045
Originator: NO

Well, a hard-return or forced line break doesn't necessarily mean that a new context is reached -- take bullet lists, for example: the segments are separated by forced line breaks, but they form a unity.

Still, it may be useful to be able to indicate paragraphs. But why not do it by inserting untranslatable things into the edit pane?

Eg, add a horizontal line into the edit pane when a forced line break occurs in the text (the user should be able to switch this off). The user can then see when segments all belong to one paragraph. In the case of list items, it should be fairly clear from the texts themselves that they are list items and not paragraphs.

[Jean-Christophe Helary]

Logged In: YES
user_id=915082
Originator: YES

I don't know what is technically the simplest way to visually "group" data, but anything that visually works should be fine. Thank you for your comment.

[Didier Briel]

Implemented in SVN (/trunk, [r10539]).

See also [#431].

Didier

[Didier Briel]

Implemented in the published release 4.1.5 update 4 of OmegaT.

Didier