It sounds as though you created something useful... but I can't make it work.  I think you need to provide better instructions as all I get is this:

This obviously adds structure to the sdlxliff and I wanted to see what this did to the files in the rest of your workflow.  Where do you run the script from?  I'm guessing it only support full projects as well given you said "target folder"

Unknown said:

Dear SDL please delete that useless " + " signs.

They are not useless. They are there to indicate to a user that there is more information available than you see in the DSI column.  Don't keep thinking you only ever see this in an Excel file... you don't.  For example:

If there was no + symbol the user would not know there was anything else to see.

yap,

the "+" sign part is "MY" wish, extremly personal. Just ignore it.

Thanks for the Good examples.

Unknown said:

I have no idea what do you mean "embedded content"...I am not good at SDL's jargon (and/or MS's too).

It only uses sdl:cell.  You can't select another... and don't tell me that's silly showing all the options and not allowing anything else because I know!

So if you overwrite that in the sdlxliff and you have used this feature to tag up content that should not be translated, like html code in the cell of your spreadsheet, or these sort of constructs {4}, %2 etc., then the embedded content feature may not work anymore.

looks like "Perfect explanation".

but, I am still "Perfect ignorant" about it.

FINE...

I gave it up. Not interested..

.

If I had some time, I will post this workaround of workaround.

1. you gather all segment numbers you want to hide with this tool.

2. now, you make all things back to original status, it is so easy, just use the BAK file.

3. finally, you use the seg numbers gathered at "stage 1", and hide properly all you wanted. 

4. you are very happy...  Never worry about the strange "I'm bedded contents.."

regards

Unknown said:

looks like "Perfect explanation".

but, I am still "Perfect ignorant" about it.

ok... take this:

I added a cople of things into your excel file and then converted them into tags so they are protected by enabling the embedded content processor in the Excel filetype.  This uses the sdl:cell structure that you overwrite.

Having tested this seeing as I got this far you don't break the file!  I guess this is because we have already used it to create the project in the first place and don't need it now, and the creation of the target file doesn't seem to need it either.  So potentially that isn't a problem.  Very interesting.

Sorry guys, but as I see it, it's actually useless in the end, because it uses internal structures of the SDLXLIFF for purposes they are not intended for.

Therefore it's just a question of time when this breaks something... something what relies on things working as they are supposed and expected to.

That's what is the biggest problem of all these Kelly Edwards' "wannabe-oneclick" creations - they are created without a proper clue how things must work and what rules must be obeyed, therefore are just worthless for any serious and proper use... unfortunately.

Programming without a clue and the faintest idea...
It's pity actually...

I agree, these quick hacks are never stable enough. If there is a specific problem and it can be lessened with a script, I am all for it. But such scripts are not applications, they are, well, quick hacks. What Kelly Edward is wishing for is not unreasonable though, and the bilingual Excel file type provides it:

I hardly work with Excel files, but if there is demand for it, might be worth cosidering to add this feature to the monolingual Excel file type as well.

Daniel

As a robust solution I agree, this isn't the way to handle it.  Really we should be able to read more into the sdlxliff file through the filetype support and then this sort of hack wouldn't be needed.

But despite this I like the inventiveness to try and solve a problem we shouldn't have in the first place.

Unknown said:

and the bilingual Excel file type provides it:

I'm afraid it doesn't. What he's trying to solve is a way to use the cell colouring from the Excel file and the problem is we don't extract it in the first place.  If the coloured cells are not regular and in one column then we don't have a filetype at all that can cater for this.  All that's needed here is for the Excel filetype to be able to extract the colours in a way they can be used.  Adding it to the DSI automatically would be a smart way to do this.

Paul said:

Really we should be able to read more into the sdlxliff file through the filetype support

Cannot agree more.
To be honest, the Bilingual Excel file type looks to me more like a "quick hack" put together for some specific need, than a properly thought-through, systematically approached and feature-complete filter... and IMHO either should not have been released at all, or should have been marked as a beta, MVP, or something like that, with clearly and publicly defined development plan for completing the functionality.

Paul said:

But despite this I like the inventiveness to try and solve a problem

Yes, sure, inventiveness is cool... but unfortunately, it's the lack of knowledge about the wider context and complex dependencies what makes it often to cause more harm than good. Especially if the product of such "naive inventiveness" is then blindly used by other clueless users who don't realize the possible (destructive) consequences... which even may not be immediately obvious and fully show up only later in the process when it's impossible to fix the harm.

Paul

I understand.

IMHO DSI is one of the weak points of Studio. The DSI Viewer App is a step in the right direction, but the problem is often to pass the information on to the SDLXLIFF.

In this case, a workaround might be to dedicate a column to contain text values with the color, e.g. the hex code. Not great, but it could be used for filtering IF there was a provision in the file type, such as the Bilingual Excel filter has it.

As you know, I have a similar grievance with XML files once I use an embedded content processor: https://community.sdl.com/ideas/translation-productivity-ideas/i/trados-studio-ideas/enable-more-document-structure-information-when-using-the-embedded-content-processor

I did find a workaround, but it is an additional step, takes time ... should not be necessary.

My guess is that Excel is one of the most frequently used file types with Studio, and I remember many Forum posts along the lines of "my client told me to only translate the yellow cells". Maybe somebody can formulate it in a concise way and post as an idea? I am sure people would vote for it.

Daniel

This idea has been extended to include this:

https://community.sdl.com/ideas/translation-productivity-ideas/i/trados-studio-ideas/enhance-the-select-criteria-for-exclusions-in-excel-files

But in truth I don't think this goes far enough.  I think there are simply very basic things that could be added to the Excel filetype for extraction that would make it a far more capable filetype when used in conjunction with the various display filters we already have.

This idea has been extended to include this:

https://community.sdl.com/ideas/translation-productivity-ideas/i/trados-studio-ideas/enhance-the-select-criteria-for-exclusions-in-excel-files

But in truth I don't think this goes far enough.  I think there are simply very basic things that could be added to the Excel filetype for extraction that would make it a far more capable filetype when used in conjunction with the various display filters we already have.