#947 Insert Next Missing Tag Pair

[Héctor Cartagena]

Problem

Depending on source file format, tags that enclose text are often not numbered as a tag pair by OmegaT. However, most of the time the user can infer that certain tags are a tag pair, for example:

CaCO<t1/>3<t2/>

A rapid look at the source document confirms that <t1/>3<t2/> represents number 3 in subscript form.

Current Feature

Today we have "Insert Next Missing Tag" (INMT) and "Insert Missing Source Tags" (IMST). INMT inserts next missing tags one by one. IMST inserts all missing tags at once.

Desired Feature

A new option, "Insert Next Missing Tag Pair" (INMTP), which inserts missing tags two by two.

Usage

After insertion, the user would use Ctrl+Left Arrow to put the cursor between the tags and resume typing.

On a selection in the target segment, INMTP would insert the first tag before the selection and the second tag after the selection.

[Aaron Madlon-Kay]

I have a couple thoughts on this.

1. I don't think it's a good idea to guess at the relationship between placeholder-type tags, so I would not be in favor of treating <t1/>...<t2/> as a pair.

2. For a given actual pair <t1>...</t1>, I suppose we could offer for insertion the set <t1></t1> even if they are not adjacent in the source.

3. I don't really think this is a big useability improvement if you then still have to navigate into the middle of the pair. But it should be possible to automatically place the cursor in the middle upon insertion.

@Admins, feel free to make me owner of this RFE.

[Jean-Christophe Helary]

In the case you give, ...<t1/>3<t2/>... is not a tag pair. XML has a strict definition for what a pair is and for what a single tag is.

The case that you give probably comes from an MS file, where the XML is not based on pairs as intended by the XML standard, but is based on single tags that represent formatting "runs". The structure is copied on RTF and as you say, the user can see that the tags look like a pair, but the truth is that the structure is more likely to be:

(default run)...<new run for 3/>3<return to default run/>...

So, superficially the tags look like a pair, but structurally nothing in their structure can give hints to OmegaT as to their real meaning, and because of that (unless we implement some very smart parsing of the original XML) OmegaT will never be able to link the 2 tags.

[Didier Briel]

In the case you give, ...<t1/>3<t2/>... is not a tag pair.

Yes but, as the bulk of work of professional translators in the .docx format, if we do not handle that case, there's no benefit for them.

Didier

[Didier Briel]

Aaron, I have assigned this RFE to you as requested.

Didier

[Aaron Madlon-Kay]

I just realized that this RFE is requesting a new command in the Edit menu. I think that this kind of advanced tag manipulation is better suited to the Autocomplete tag view, so I have implemented it there in r5932.

[Aaron Madlon-Kay]

In the autocompleter Missing Tags view, now in addition to the previous tag groupings there will be tag pairs.

Tag pairs are shown as <t1>|</t1> or <t1/>|<t1/> (open-close or single-single are the only pairs recognized). Upon selection, the tags will be inserted and the cursor will be placed where the | indicates.

[Didier Briel]

Given the fuzziness of pairing single tag, using the autocompleter is fine.

Didier

[Didier Briel]

Implemented in the released version 3.0.8 update 3 of OmegaT.

Didier

[Jean-Christophe Helary]

I just tried the feature and it works very nicely. There is one thing that would be great with pairs insertion (<t1/>|<t2/> for ex), is that when there is a selection in target and such a pair is selected, the selection goes in place of the "|".

[Aaron Madlon-Kay]

@JC I was thinking the same thing. This is now implemented in r5943.

To be clear: When there is a selection in the editor such as bar in

foo [bar] baz

and the user selects a tag pair such as <f0>|</f0> in the autocompleter, the result will be

foo <f0>bar</f0> baz