Nathanael Fourie 

Have you tried searching for \.$ and leaving the replace blank?

It seems so simple I'm wondering what you're not telling us?

Nathanael Fourie 

I just installed the toolkit and tested to be sure..

It finds it in the search:

The preview shows it replaced:

But then the actual replace operation fails!

So perhaps this is really what your question relates to?

Lydia Simplicio  - one to log for resolution :-)

Thanks Paul 

Your code worked. Searching for (.+). and replacing with $1 also works.

From SDLXLIFF Toolkit, I tried it on a few test sdlxliffs, and then on the actual, live project source sdlxliff.

Using Notepadd++, I can see that the full stops have been removed, but when I open the file in Editor the full stops are still all there. 

Is there something I'm doing wrong?

Nathanael Fourie 

Indeed... in fact a better code for me is \.+$

But this won't work anyway as it seems to be a bug in the toolkit.  It works in target... but not in source.  So yo are not doing anything wrong... the plugin needs fixing.

Nathanael Fourie 

Indeed... in fact a better code for me is \.+$

But this won't work anyway as it seems to be a bug in the toolkit.  It works in target... but not in source.  So yo are not doing anything wrong... the plugin needs fixing.

Ok, thanks, Paul !

Any other way you can perhaps think of (that actually works) to remove all the full stops from the end of the source segments, without having to do it by hand?

I've got close to 2000 source segments to edit, and I'd really like to get to the actual translation. Big deadline for tomorrow... :&

 Nathanael Fourie 

You could take a copy of the sdlxliff and do it in a text editor using regex?  Test the sdlxliff afterwards and if you didn't break it you're good to go.  For example:

Search for:

(<source>)([^.<]+)\.+(</source>)

Replace with:

$1$2$3

But be very careful and check it.  I don't have your files and the very simple test I just did with my own file may not match what you have.  So take this approach:

1. Back up your current sdlxliff file from your target folder by copying it into a new folder somewhere safe.  Then you can easily put it back
2. run the search and replace on the sdlxliff file in your project in a decent text editor
3. open the project and test it to make sure of the following at least:
   1. you can still open it,
   2. the changes are correct, 
   3. you can save a target file
   4. etc.

If anything is broken you easily recover by copying the one you backed up back into the project.  In fact I think I'd even back up the original project just to be sure!!  It's always risky playing with sdlxliff files natively, but it can indeed be a quick way to make changes if you're comfortable with it and understand the risks.

Any chance I might have removed the full stops in the incorrect sdlxliff?

Should I have searched and replaced in the target sdlxliff file?

Anyways, I did it for both source and target sdlxliff file, and then copied the target one, rename it slightly, and pulled it into the project as a source file and voila, no more additional full stops.

On the contrary, I just opened up and checked the other project file (which is an sdlxliff file), i.e. the original file I performed the search&replace operation on while working on it live, and now that file also has the full stops removed (contrary to earlier on, when I was flipping in and out of my live project and other ones, so as to refresh the content of the original file I had been working on, but then the full stops were still showing all the time).

That's a bit weird, so I don't know if it has something to do with the Toolkit app or Trados, but the changes definitely weren't showing for a significant amount of time, which is why I thought of copying and renaming the target sdlxliff project file and adding it as a new source/project file.

Any thoughts on the above, Paul ?

Nathanael Fourie 

Nathanael Fourie said:

Should I have searched and replaced in the target sdlxliff file?

Yes, unless you intend to use the sdlxiff as the source file for a new project in which case changing in this might be beneficial, especially if it's a multilingual project.  Although in practice it should not matter seeing as you can do all the files in one go with the toolkit (when it's working!)

Nathanael Fourie said:

Any thoughts on the above,

Other than that I don't.  I don't really follow what you did here but I also don't think it matters.  The toolkit definitely doesn't work correctly when attempting to change the content in the source.  So we need to fix it.

If you managed to resolve your problem then that's a perfect result.  We'll make sure it's easier next time!