Some clients abuse non-breaking space in MIF (Adobe FrameMaker) files to keep body text together. This results in sentences with many tags.
My request: please let CafeTran handle these non-breaking spaces as 'normal' non-breaking spaces (rather than as tags). An option in the Project Configuration dialogue box would be great.
If this would be necessary because of a technical reason, it would be acceptable to replace the non-breaking spaces with normal spaces. Ideally, non-breaking spaces inserted as Unicode spaces in CafeTran projects, would be exported as MIF non-breaking spaces.
In the image below, tag #1 is such a non-breaking space:
The problem with these non-breaking spaces (handled as tags) is also, that they are stored the wrong way in the TM (namely as being glued together).
Here is an image:
(is this function broken?)
Well this is definitely strange. Source segment pane:
Note the non-breaking space before the (1).
When I use my Keyboard Maestro macro to search for this segment in my PDF, the correct segment is found:
This is of course great news. But what does this mean? Does this mean that CafeTran internally treats these non-breaking spaces as ... non-breaking spaces? Some clarification would be welcome.
MIF files represent such spaces as tags. Internally, CT treats such a tag as a space to allow the proper recognition of words.
Would it be possible to have them displayed as tags in the Target segment pane too?
I don't quite understand what you mean. They are represented as tags in the target segment after the tag transfer.
Okay, now I understand. They are currently represented as a tag indeed, which in many cases leads to strange visual effects (words being apparently being glued together, see the screenshots above).
I also assumed that segments with these tags (representing non-breaking spaces) would get stored in the glossary and TM the wrong way (namely glued together). I've just learned that this isn't the case (very good), and also found that while adding words to the glossary (without making selections in the Source segment pane and in the Target segment pane), these words are added correctly, that is: with spaces:
Added to the glossary as:
So, what's left to wish for?
Related to this, but not less important (at least for me): I'd love to have a filter option to have dashes treated as (deletable!!!) Unicode dashes instead of tags. This is causing me head breakens:
The dash shouldn't be there in the target! I can of course position it at the end of the segment, but that looks really stoopid.
Okay, to make this list complete: the third option for the MIF filter would be an option to remove unwanted linefeeds:
Again, I can place these linefeeds (the result of sloppy formatting 'the typewriter way') at the end, but that doesn't really solve the problem.
I feel that I owe you some explanation. So I'm happy to provide it!
Why are these new lines problematic? Well, you have to make sure that you position them exactly as in the source, or else you will get so much false positives in your QA tags, that this important task cannot be executed without getting insane. So for your own peace of mind, you have insert them during the translation process very carefully. Which is a boring task, hence my today's state of mind.
The better CafeTran gets (and it gets better by the week), the more boring I find stoopid tasks like inserting tags that aren't necessary at all, but are the result of sloppy formatting. Is this just the feeling of a totally spoiled trhanslator or do you recognise some of it?
There is some other thing important here, just found out ...
CafeTran resolves references to chapter titles and the like. It shouldn't do that. It should treat them as a tag.
Until this has been implemented (the correct handling of REFs), I think that it's wise to prepare your MIF project in another CAT tool.
I hope that the MIF filter will be improved soon.
>I hope that the MIF filter will be improved soon.
The REFs are now handled as tags: great! CafeTran is now in line with the other CAT tools, regarding this handling.
Not sure about the non-breaking spaces, yet.