strange..
If I were You, I just delete Tags (head tag and tail tag) part only at target segment

"Externalize" is clearly a serious design mistake.
It should be placed inside of it (segments).

Its structure goes like this.

<trans-unit id="59db3c7f-6a57-4a26-b0ba-3aeaa8edd540">
   <source>
         <g id="17">Mother Mary comes to me</g>
   </source>
   <seg-source>
         <g id="17">
               <mrk mtype="seg" mid="2">Mother Mary comes to me</mrk>
         </g>
   </seg-source>
   <target>
         <g id="17">
               <mrk mtype="seg" mid="2">Mother Mary comes to me</mrk>
         </g>
   </target>
</trans-unit>

Where "<g id = 17>" is the italic part.

Unknown said:

"Externalize" is clearly a serious design mistake.
It should be placed inside of it (segments).

The tags are moved out of the visible text in the editor cell, so that a) they don't pollute the text and translator is not distracted by the tags and can focus on the actual text, and b) the text which subsequently goes into TM is also not polluted by extra tags (which could then later lead to match penalties due to different/missing formatting).

I suppose you don't remember Trados 2007 TagEditor which displayed ALL tags... That got really EXTREMELY messy for taggy files... and I fully understand that translators did not like it.

The idea of externalization was obviously driven by good intentions... but as we know, the road to hell is paved by good intentions, so we now see the consequences... ;-)

I do not like talk with a little bit biased people.
Of course posting ones idea is not a bad idea at all though.

whatever it is/was.

Now I have found Really easy (and really tedious) workaround for the people who likes strange talking.

Point is very simple.
"Finish it" - If you start a Tag then finish it at the same place.

Let's see the screen shot(s) first.

the 1st is problem itself
the 2nd is the completed

the trick is complete it first at EndTag, and then at StartTag
that means, copy StartTag into EndTag first.
otherwise the file goes crazy

Yes, this Externalization is crazy itself. Nothing else.

Enjoy Crazy Driving..

If you do not like this silly tedious procedure, make your own PlugIn then your life will be much happier than now.

Unknown said:

"Externalize" is clearly a serious design mistake.
It should be placed inside of it (segments).

You're so wrong!  Moving unwanted tags outside benefits users far more than the other way around.  But I can see the value in having an option to prepare files with the tags internalised if you want.

"Wrong"
Wooo, you could be Right

Now, Look at the fact, the Wrong guy solved problem. Right ?

What is good at this place be Problematic Right ? I am fully satisfied with Problemless Wrong as you mentioned.

Unknown said:

If you do not like this silly tedious procedure, make your own PlugIn

You still don't seem to understand that not everybody (especially not linguists!) can code, especially not using the crazy .Net hell, requiring dozens of megabytes of libraries just for Hello World :(
And that your way of making a separate plugin for every little one-off sh*tty task is especially crazy...

Plus, I remember very well your beginnings in the forum, when you flooded (under your previous account) the forum by dozens of, well, pretty lame, coder-beginner's questions to which you would find answer if you would actually read the documentation and use some basic programming knowledge.
So playing a big "make your own plugin" hero just a few months after you didn't even know yourself what plugin is and how to make it is kinda funny...

Okay, I just felt the need to express my opinion, this is not meant as flamewar and I will not take part in one.

Unknown said:

If you do not like this silly tedious procedure, make your own PlugIn

You still don't seem to understand that not everybody (especially not linguists!) can code, especially not using the crazy .Net hell, requiring dozens of megabytes of libraries just for Hello World :(
And that your way of making a separate plugin for every little one-off sh*tty task is especially crazy...

Plus, I remember very well your beginnings in the forum, when you flooded (under your previous account) the forum by dozens of, well, pretty lame, coder-beginner's questions to which you would find answer if you would actually read the documentation and use some basic programming knowledge.
So playing a big "make your own plugin" hero just a few months after you didn't even know yourself what plugin is and how to make it is kinda funny...

Okay, I just felt the need to express my opinion, this is not meant as flamewar and I will not take part in one.

Wooo

I would like to give you the same wordings minutes ago Paul gave to me. OK ?
"You're so wrong !!! "

In my personal and very smart opinion.
The Powershell is a really sh*t.
That is the degenerated mutation of the great .NET

ok  Evzen Polenka 

I think we need to stop this thread now.  You are both out of line and I'll block you if this carries on.

Powershell is an excellent tool for people who focus on workflow with no bells and whistles.  It's easier to use and fast.

.NET is a far more capable programming medium and supports developers creating things that would not be possible in powershell at all.

So I think we should draw a line under the discussion at that.

Unknown said:

In my personal and very smart opinion.
The Powershell is a really sh*t.
That is the degenerated mutation of the great .NET

I'm not any adorer of Powershell.
The reason I used Powershell for Studio automation is that it's the only viable way to do it via scripting (because SDL made the Studio automation way harder by abandoning the COM API... idea obviously driven again by good intentions (making internal plugins) but totally ignoring the fact that people need to use automation also other ways than by clicking buttons in GUI and also the fact that not everybody is a developer.

Another reason to use Powershell is that I WANT and NEED to produce USER-EDITABLE scripts, so that anyone can just open the script in a simple text editor, make a change/fix/enhancement and IMMEDIATELY run it, without any additional compilation, etc.
That is the real power of scripting (which most of today's C# youngsters-hipsters would not understand).

Unknown said:

.NET is a far more capable programming medium and supports developers creating things that would not be possible in powershell at all.

Just a quick last line...
Powershell can do whatever the underlying .Net can do, so .Net is definitely NOT "far more capable of doing things that would not be possible in powershell" ;-)

Unknown said:

Powershell can do whatever the underlying .Net can do, so .Net is definitely NOT "far more capable of doing things that would not be possible in powershell" ;-)

Hi Evzen Polenka 

ok - I wanted to keep this fairly simple because I think powershell is more of a quick way for system administrators and people looking for simple ways to quickly run a task to work.  I probably should of made it clear that the difference really is that Powershell only consumes .NET so as a C# developer for example there is a lot more you can do programmimg directly in .NET then you can using powershell.  It's also a lot faster, secure and more performant once you have a compiled application.  Take the BaccS plugin, or Qualitivity for example.  I cannot imagine the effort it would take, and it might not even be possible, to write applications like this that work efficiently using powershell.  You're also limited to what is made available to a powershell user whereas a c# developer can do pretty much whatever is needed and use a variety of other technologies in the compiled application.

It's interesting that we have so few powershell users compared to C# developers in the community.  Must be a reason for this as it's certainly easier to learn powershell.