Since we are talking about formatting & capitalization shortcuts I
suppose first of all we need to implement tags insertion shortcuts.
We have two types of tag groups: pairs and singletons.
A pair would be inserted by selecting the applicable string and hitting a
shortcut based on the selected group number (alt-n ?)
A singleton would be inserted at the cursor position with a similar device.
We need to implement the shortcuts for the o to 9 series to enter tags
directly.
And for group numbers that are superior to 9 we need a generic device
that takes any number as a argument, similar to "go line nnn" in text
editors.
Logged In: YES
user_id=1343245
And if you have 10, 20 tags?
I'd rather have something like a single shortcut: "insert
next missing tag".
This would insert the first/next tag present in source and
not in target.
This would go with the typing:
You type the first part of the sentence. When you arrive
at the first tag, you hit "insert next missing tag", etc.
Didier
Logged In: YES
user_id=545103
I'd rather see something more flexible, cause I regularly
need to reverse tag order, duplicate tags, or otherwise
change the tag order.
Perhaps a combination of both your suggestions would suit
me. I could simply use Alt-T (or something) to insert the
next missing tag, and when I need to modify the tag order, I
could use Alt-<nr> to insert a tag by its number. In the
rare case (for me) that I have a segment with 10 or more
tags, I could still copy/paste tags, or type them myself. It
would happen that infrequently, that I wouldn't feel it as
a problem.
Logged In: YES
user_id=1343245
About the number of tags:
The issue is not the number of tags in the segment, but
the number of tags in the paragraph.
I often have long paragraphs, which means even if there
are 2 or 3 tags in the segment, they can have number 12,
13 and 14.
Didier
Logged In: YES
user_id=915082
Didier is right about the numbers. It depends on the size of the paragraph.
That itself is a bug since the segmentation should be created at the same
level as the default segmentation so as to create tag groups that dont spread
over a number of segments.
But that left aside, and considering that target language structure can
sometimes be funky only having a "insert next tag" would be sometimes
limiting.
Plus we need something that would actually be shorter to type than to type
the segment itself ;)
I think modkey+nb (0~9) is the fastest way to deal with simple cases and
modkey+t (input dialog) + (n+) would do it for any tag number.
Logged In: YES
user_id=1343245
<<That itself is a bug since the segmentation should be
created at the same level as the default segmentation so
as to create tag groups that dont spread over a number of
segments.>>
It's a trade-off. It depends I guess whether the
repeatability is more at the paragraph level or at the
sentence level.
<<modkey+t (input dialog) + (n+) would do it for any tag
number.>>
Well, for me it would be nearly faster to type the tag.
But I’m not against it, as long as we have the “insert
next tag” too, as Henry suggested.
Didier
Logged In: YES
user_id=915082
If sentence segmenting is on then the project should segment using sentence
rules at the same level as paragraph "rules".
Re. the <<modkey+t (input dialog) + (n+) would do it for any tag
number.>>, it would not be longer for paired groups: select, modkey+t+nn
+enter: 5 keys with 2 digits vs "<lnn> displacement </lnn>" 11 keys +
displacement.
For single tags, agree with you though.
Logged In: YES
user_id=1343245
<<If sentence segmenting is on then the project should
segment using sentence rules at the same level as
paragraph "rules".>>
And then when you resegment (happens often to me during
the first two days of a project), then all your tag
numbers might change. That's why I wrote it's a trade-off.
Didier
Logged In: YES
user_id=545103
Concerning tag insertion, how about this?
- CtrlCmd+Alt+<0..9> inserts the tag with the number pressed
- CtrlCmd+Alt+N inserts the next missing tag
- CtrlCmd+Alt+T brings up a dialog where you can type
numbers larger than 9
That amount of flexibility would nicely fit all users I reckon.
Logged In: YES
user_id=915082
Ok, when you mean insert you (must) mean:
insert opening tag before the selected part and closing tag after selected
part.
+
insert single tag at cursor position
selecting the number of a tag pair when nothing is selected should insert the
pair at the cursor position.
selecting the number of a single tag when something is selected should do
what ? insert the same tag right and left of the selected part ? (why not) ?
Logged In: YES
user_id=545103
Yes to all except the last bit. When inserting a
single/stand-alone tag, I think what people would expect is
that it would be inserted in place of any selection.
Logged In: YES
user_id=915082
But then it would not be consistent with the tag pair placed on the right and
left of a selection.
Obviously this is not "typical" select+paste behavior that we are considering
here. It is more an "apply style on this selection" since the tags are supposed
to be equivalent to inline style.
I think in the doc we should be clear about that: we are not pasting strings,
we are applying an inline style to a selection.
Logged In: YES
user_id=545103
It's not about applying style either, cause single tags are
never used for styling text.
You are right about one thing though. Adding start/end tags
around a selection, but replacing a selection when inserting
a single tag is not exactly consistent behaviour.
However, I wouldn't expect an application to insert 2 single
tags when I have a selection either.
Logged In: YES
user_id=915082
What really matters is how we show that in the doc.
Inconsistence can look ugly is badly presented, and look very smart otherwise.
So what about inserting single tag before selected string (considering that
selection was not intended).
Logged In: YES
user_id=545103
Actually, I like the idea of replacing a selection by
inserting a single tag. That'd be very useful for tag
correction, selecting incorrect tags and inserting correct ones.
Logged In: YES
user_id=1343245
<<Actually, I like the idea of replacing a selection by
inserting a single tag. That'd be very useful for tag
correction, selecting incorrect tags and inserting correct ones.>>
I agree with that. It's consistent behaviour, and seems useful to me.
<<(considering that selection was not intended).>>
Well, if we begin to consider user actions are not intended... :)
Didier
Logged In: YES
user_id=1630149
>> (considering that selection was not intended).>>
>
> Well, if we begin to consider user actions are not intended...
I see a very small 2.0 version, with just one dialog class,
containing just two localisable string: "OmegaT thinks you
did not intend to start a translation. Therefore OmegaT
shall now quit.", "OK" (button).
I think I can make that release by 1 November :)
Logged In: YES
user_id=1343245
Originator: NO
[ 1350244 ] Make OmT tags into placeables
discusses the same thing (inserting tags).
Perhaps these two RFE should be merged.
Didier
Logged In: YES
user_id=545103
Originator: NO
More information at RFE 1350244 - Make OmT tags into placeables
http://sourceforge.net/support/tracker.php?aid=1350244
From Kos Ivantsov
- Insert Source Tags
http://sourceforge.net/support/tracker.php?aid=2873562
<<Would be really awesome if OmegaT was able to insert Tags separately from
the source segment. Just tags. Like we have a menu item for inserting
source or match, but in this case it's not actual text that we want to
insert, it's tags.
There are third party scripts that do that, but I'd think it can be done
with OmegaT itself (well, it can analyze tag errors).
And then, if it's doable, maybe it would be beneficial to be able to insert
all the tags at once ("Menu —> Insert All Source Tags"), and one by one
(pressing "Menu —> Insert one source tag" for the first time in a given
segment would insert the very first tag from the segment, and every time
this item gets pressed again in the same segment, it inserts next tag)>>
Didier
From another report (http://sourceforge.net/support/tracker.php?aid=2913756):
smolejv wrote:
<<
Precondition: the system keeps track of what "this tag" is, indicating it
with an underline or some other kind of highlighting
Allow the user to
a) copy the tag, "this tag" is pointing at, to the current position in the
target. Open: ... and move "this tag" to the next down the line. Rationale:
they usually turn up in the target in the same order (just different
place),
b) move "this tag" back to the previous tag in source - up to the first tag
in the source
c) move "this tag" forward to the next tag in source - down to the last tag
in the source
This would require three new shortcuts - suggest Alt-back, alt-down and
alt-forward, which is rather fair as regards the set of shortcuts still
available. This is a pretty "industry-standard" way of handling tags.
I am entering this, because it's been asked now and again and I have not
found any place in the RFCs, where this is explicitely suggested.
smo
>>
Didier
We now have tag insertion shortcut, plus a special page in the auto-completer to insert tag groups.
Do you still think this RFE is useful?
Didier