Unknown said:

Another question I have is about the tag <internal-file ...> within sdlxliff files: what is all this "garbage" about?

I don't think that wanting to program an (SDL)XLIFF manipulation tool without appropriate knowledge of XLIFF structure is a good idea...

docs.oasis-open.org/.../xliff-core.html

Hi Pascal

Here is the XML Schema that documents every SDL extension to the XLIFF format.
You can use this to validate your SDLXLIFF after you modify it. I believe as long as your SDLXLIFF conforms to this schema (and the XLIFF schema), it can be loaded in Trados Studio!

Sdl.FileTypeSupport.Bilingual.SdlXliff.Xliff.sdl-FilterFramework2-1.0.xsd.zip

P.S.: Sorry for not replying back to your questions about my Cleanup Plugin! I will try to get to them sometime (work is busy...)

Hi Do Lee (DoLee)

It's an embedded resource inside of the Sdl.FileTypeSupport.Bilingual.dll
You can view it with a decompiler like ILSpy.
I find looking at the code is the only way to understand how Trados Studio works sometimes.

Is there any other standards for SDL stuffs ?
(for instance, Tag rules etc.)

Not sure what you mean by "Tag rules". If you had a specific question, I might be able to help.

Unknown said:

who said I did not know about xliff structure. I already know about that reference page. ;)

Then I would expect you already tried to base64-decode the content and found out yourself that it's the source file (as the "original" attribute of the "file" element already suggests).
And since you asked that newbie-like question...

Modifying SDLXLIFF without SDL's framework can be very tricky... for example even "prettying" the SDLXLIFF XML structure prevents the SDLXLIFF from being opened afterwards...
That most probably means that something actually relies on physical position inside the SDLXLIFF file rather than on the XML structure... I'm just guessing and never actually did any further research, but the following pretty much support this idea (content is pretty-printed for demonstration purpose):

Unknown said:

who said I did not know about xliff structure. I already know about that reference page. ;)

Then I would expect you already tried to base64-decode the content and found out yourself that it's the source file (as the "original" attribute of the "file" element already suggests).
And since you asked that newbie-like question...

Modifying SDLXLIFF without SDL's framework can be very tricky... for example even "prettying" the SDLXLIFF XML structure prevents the SDLXLIFF from being opened afterwards...
That most probably means that something actually relies on physical position inside the SDLXLIFF file rather than on the XML structure... I'm just guessing and never actually did any further research, but the following pretty much support this idea (content is pretty-printed for demonstration purpose):