Start a new topic

Hide segment boundary tags... but only them

Hi,
CT also hides adjacent tags by default when "Hide segment boundary tags" is selected. This should be fixed, since a segment can start with a boundary tag AND one (or more) adjacent tag(s). This happens very often in my case, and I have to unselect "Hide segment boundary tags" option, otherwise I cannot see the non-boundary tags at the beginning of the segment.

image


(And I suspect that is also has a negative effect on the automatic tag placement efficiency when "Processing tags" is selected in a TM Options.)

 


I second that. Example:
<formatting option><symbol> This is an example.</formatting option>
will show up as
 This is an example.
(with leading space)

If you are unaware of that, you will eliminate the leading space and make a rather ugly mistake.


Another example is:
<formatting option 1>This is an <formatting option 2>example</formatting option 2></formatting option1>

This will show up as

This is an <tag>example


If you need to change the syntaxis, you are lost (and if the formatting option is not displayed in the grid, things can turn bad. At least here  you can have a look at the tag with F3 to identify the tag, deactivate "Hide boundary tags" and make your work, but this keeps being more complicated than in many other tools (even if "Hide boundary tags" is deactivated).

One more (quite serious) problem...
With a 100% match, CT will does as follows:

image


Wrong. Tag 1 should stay at the beginning of the segment, tags 2 and 3 should surround XXX.

After translating a few hundred segments, I did a QA on tags and, as expected, I got lots of errors like the above (within the autopropagated segments).

I also wanted to verify the tags content, but the F3 shortcut shows only the source tags content. Is there any way to verify the target ones without opening the xliff file in a text editor???

I really enjoy CT, but tags often become a nightmare.

Tags auto-insertion is not a foolproof feature. CT 'guesses' tags position in the target segment based on their (merged) position in the source segment. With some complex tagging, which you can come across in the projects created in other translation tools, the user needs to correct their position manually. The feature is finely tuned for CT native project as the program reduces the number of tags to absolute minimum during the creation of the project.

Hi Igor,

As far as I can judge, CT is quite good with automatic tag placement when boundary tags are hidden in the editor. Problems appear when I do not hide them.

Correct me if I'm wrong, but I tought that CT's boundary tags were simply <x0> and </x0>.
So, if I'm not wrong, it would be simple to tell CT to do not hide <x1>when a segment starts like this:
<x0><x1>some text</x1>some text...</x0>
... or is it more complex than that?
From my point of view, it is far more complex, as we simply don't live in an ideal world. There can be occurrences of

<x0><x1>some text</x1>some text...</x0>


But in real life, the tag can have different forms. It can be a simple formatting tag (bold) or a complex formatting tag that i much harder to catch (font type, font size etc.). Or imagine


<x0> This is a bullet point with some <x1>bold text</x1>


In this case CT hides <x0> and </x1>, and as a user you must guess what the leading space is for.


The annoying thing is that CT rund a lot smoother with hidden boundary tags, so the option to uncheck it indeed is viable, but unpleasant.


On the other hand side, and there I would second Alain, in the eman time other tools are able to recognize, extract and export simple formatting tags (bold, italic, underlined) in Studio files.

Hi tre,
I thought that <x0> and </x0> were simply some default tags of CT's flavor to separate segments, so they could easily be isolated from the other tags.
I guess I was wrong... too bad. :-)

 

Well, I am only a silly user, but have a look into the source text of a sdlxliff or mqxliff file (not to speak of many other formats). This is what CT needs to to recognize and process.

 

Even with native formats (docx etc.) formatting and its tags can get highly complex.

I also looked many times at my sdlxliff files as a silly user. My conclusion was that, at least with xliff files, CT converts <target> and </target> tags respectively to <x0> and </x0>. I guess I was wrong... ?
No, for sure this is not the case.
Look at this example:

image


The already translated target is:
<g id="373"><mrk mtype="seg" mid="75"><g id="374">R</g><g id="375">esultate</g></mrk></g>
There are two alternatives:
  • Simply mask these tags (this is a kind of what CT actually does, I suppose)
  • Look somewhere else in the sdlxliff file for a definition:

image

  • You see that this is a highly complex task (but it would be nice to have it accomplished, one day, at least for simple formatting)



 

@tre


Tags handling in that file format borders on quantum mechanics (the tag definition and its appearance in the real segment are remote but "entangled") :)  Don't get me misunderstood, quantum mechanics is fascinating stuff but exact reverse engineering of file formats created in other translation tools is a very complex task (and not that fascinating). I have been making some shortcuts to be able to handle such tags, more or less the same way CafeTran handles them in its own native projects.


@alain


I will look into the possibility of hiding only the first initial and the last ending tag soon. 

> and not that fascinating

Indeed, I was a bit surprised how complicated nowadays Studio handles rather simple formatting (I had a simpler approach in memory, maybe Studio 2009).

And when I see the simple formatting interpretation in that other tool(TM), I am rather unsure about its error-proneness.

> I will look into the possibility of hiding only the first initial and the last ending tag soon.

Great (as here).

 

Indeed, I was a bit surprised how complicated nowadays Studio handles rather simple formatting (I had a simpler approach in memory, maybe Studio 2009).


That's a "conspiracy theory" but I have a hunch they are making it complex on purpose. Of course, that would be perfectly understandable. Life! :) 

Login to post a comment