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.

[minor_Updated]

now

1A1 : the first worksheet's cell A1

2A1 : the 2nd worksheet's cell A1

extract_sdlxliff_Advanced_dsi_Updated.zip

funny enough.