User-defined tags

Logged In: YES
user_id=915082
Originator: NO

looks like it can be considered a duplicate of Samuel's "[ 1363757 ] Generic tagged-text filter".

what do you think ?

Logged In: YES
user_id=545103
Originator: YES

Not really a duplicate. Samuel is looking for a filter that looks for occurrences of fixed markers. The user would have to add those markers in his source documents himself. The marked up portions wouldn't be displayed by OmegaT. What I'm looking for is additional functionality on top of all file filters, where the user can define strings that shouldn't be touched by the translator, but which are included in the displayed text. When presented and handled as tags, this is not confusing for the user, and OmegaT already has built-in functionality to check for correctness of these strings.

Logged In: YES
user_id=915082
Originator: NO

I understand that they are not exactly the same thing, but they refer to a quite similar concept:

in one case the user defines segmenting tags (hence invisible)
in the other the user defines inline tags (hence visible)

Which is exactly what we have for formats like HTML/DocBook/ODF etc... So, for me it is the ability to define a whole new file format by inputing the block/inline tags (and I think _that_ is actually a very old RFE).

Logged In: YES
user_id=545103
Originator: YES

I'm not talking about file formats or filters. I'm talking about functionality on top of file filters, so I can have that for any file type. (I've encountered these things in 3 different file types so far.)

Logged In: YES
user_id=915082
Originator: NO

well, having that for _any_ file type means applying your settings to *.* files.

what matters is that such tags (inline or block) are handled as the "traditional" ones in OmegaT. as far as the user is concerned, they should be exactly the same thing.

besides, having such functionality would allow for shortening actual tag groups like we have in RFE 1587697: "shortening of tags series containing _no_ translatable parts"

because OmegaT should not care whether the tags are actually present in source or after it has processed them as OmegaT tags.

or am I going way too far ?

Logged In: YES
user_id=545103
Originator: YES

It depends on what level you'd implement it and whether it'd use regular expressions. I think if we process strings after they've been read by file filters, but before they are displayed, then that would indeed allow for shorting your tag series. You'd just enter a regex similar to (<\S+\d+/?>)+, or (<\S+\d+/?>\s*)+ if you wish to include whitespace also.

fixed. a regular expression for custom tags can be entered via the tag validation option dialog.

It is checked if the number of tags and the order is identical (just like omegat-tags, not like printf and java tags)

The tags are also rendered as tags (grey, just like omegat-tags, see #2120329) and inserted when inserting tags (ctrl-shift-t)

Implemented in SVN (/trunk).

Didier

Closing...
This feature was implemented in the released version 2.5.1 of OmegaT.