Menu
▾
▴
#766 Optional to highlight spaces next to tags
Problem: Spacing before and after tags is very important but is not always very visible to the translator. Inserting a space can create an unwanted space in the middle of a word in the target file, or removing a space can cause words in the target file to be concatenated (and a spellcheck would not necessarily pick it up). For tags that relate to line breaks etc, a missing or extra space can cause unwanted indents or misalignments in the target file. Unless the user is using a fixed-width font, it is very difficult to see spaces next to tags.
Solution: Allow an option that highlights spaces next to tags, e.g. in yellow. In other words, in the source text (and possibly in the target text also), if a tag is preceded or followed by a space, that space is highlighted in yellow.
This is indeed a problem. I have already suggested (not as an RFE) a different solution: a feature to hide tags, to make reading through second and subsequent drafts much easier. This would be a read-only mode; in order to make any changes, the translator would have to switch back to tags unhidden mode.
@Marc: Hiding tags won't help the translator see which tags should have or should not have spaces next to them. The problem is specifically the fact that the translator can't see the spaces (or lack thereof) easily -- the examples I gave were just examples of why this is a problem. Highlighting spaces next to tags is what I do in MS Word in WFC when translating tagged text, and I find it a very useful and easy way to keep an eye of spacing during translation (not as a separate process).
My specific issue is that if I have something like:
After 15 m<f1>2</f1>there is a space missing.
I am more likely to spot it if I can see:
After 15 m2there is a space missing.
And by the same token, if I have:
After 15 m<f1>2 </f1> there is a space too many.
I am more likely to spot it if I can see:
After 15 m2 there is a space too many.
> Hiding tags won't help the translator see which tags should have or
should not have spaces next to them.
With regard to the above issue, hiding the tags does help (me at least). Using the text export function, I wrote a script to do precisely this and you can download it at www.omegat.org/omegatk/te-scripts.zip. I used it routinely for a while after switching to roundtripping via .docx. (I forget why I stopped using it; it may have been when the tag aggregation feature was added.)
The lighter grey for tags has also helped a lot.
Your issue, I think, is something different (i.e., if so, my issue is different and I'm hijacking your RFE). If you need to know whether
1<f0>This is a heading
or
1 <f0>This is a heading
is correct for example, my "hide tags" suggestion won't help. What would be useful in this case would be an indication of some kind of when a tag is preceded and/or followed by a space in the source but not in the target, or vice-versa, similar to the validate tags function. That might even be possible as part of the language checker.
There is yet another issue in that some tags (in .docx files for instance) have the meaning "delete space" or "insert space", which is a real nuisance.
@Marc: The thing that caused me to submit this RFE was when I realised that the "insert tags" function in OmegaT adds spaces between tags even if there are none in the source text. This means that the translator has to delete the spaces manually, and anything manual can more easily lead to either mistakes or sloppiness. I also realise that not everyone uses a font that shows spaces clearly.
A validator has its place, but a validator is something that runs afterwards, and is prone to false positives, and a user might be tempted to gloss over the report, particularly if his deadline looms. I'm in favour of something that does not interrupt the user's workflow yet provides the necessary information. Even per-segment validation that gives an error message is still something that interrupts the user. With colours, the user can decide at a glance whether the spaces are important to keep or not.
A validator also assumes (implies, perhaps) that the thing that is tested is the norm (i.e. that spacing in the source should normally be the same as in the target), but that is quite often not the case with spacing. Take, for example, a case where the source text tag is followed by a punctuation mark e.g. a comma whereas in the target text there is no comma and hence a space. In such a case the space is good, not bad, and a translator does not want to have to deal with such false positives in a validator report.
> The thing that caused me to submit this RFE was when I realised that the "insert tags" function in OmegaT adds spaces between tags even if there are none in the source text. This means that the translator has to delete the spaces manually
I have noticed that too, and agree with your conclusions. But wouldn't it be simpler (theoretically), with regard to this particular issue, for the tag insertion routine to be corrected so that the spaces aren't added?
> A validator has its place, but a validator is something that runs afterwards, and is prone to false positives, and a user might be tempted to gloss over the report, particularly if his deadline looms.
The "validator" analogy was a broad one. I was thinking more of a function that highlighted spaces adjacent to tags (and their absence) in the way that you are describing, but only in the event of a discrepancy, not in all cases. I find tags distracting; I would find highlighted bits of the text also distracting. There's a trade-off here.
There are likely to be cases where the discrepancy is desired, of course (just as there are with tag errors), but they tend to be rare.
Coming back to my "hide tags" feature: it isn't just that it makes it easier to spot superfluous or missing spaces adjacent to tags; it makes reading the text (both source and target) much easier.
@Marc: 1. Until OmegaT tags can be protected and until OmegaT's cursor movements can treat tags as word units, I think the spaces in the inserted tags are good -- they help the user see the different tags and help him place the cursor in the right place.
2. Something that highlights only when there is a discrepancy assumes that only discrepancies are important. Discrepancy is not really an issue for spacing (as it is with tags themselves) because different languages do different things with spacing.
3. What is important is that the user can see the spaces with a single glance without having to interrupt his flow of thought. I'm sure the highlights would be confusing to some users, which is why it should be an option, but for power users the highlighting will help them translate more accurately more quickly.
4. "hide tags" would be a separate RFE, possibly with an RFE about tag shrinking (i.e. down to a single character such as a little square).