Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Published Content Encoded Incorrectly in Target Variations

  Asked By: Antoinette    Date: May 17    Category: MOSS    Views: 1176

My content authors have been busily updating our MOSS publishing site, but when we published we noticed a problem. Some of the characters in the text which are correct in the source variation get turned into odd characters in the target variations. I've checked it out and all targets are effected, whether they are the same language and locale as the source variation or not.



Below is some example text from the Source and one of the Targets. Both sites are Language; English (United States) Locale; English (United Kingdom). (Not that that seems to matter)



There are 3 sets of examples below;

The page text as it displays.
The markup in from the edit view.
The content taken from the AllUserData table in the content database.
Any ideas how I can prevent the publish action from mangling my text? I would rather not have to build something into the translation workflow to fix this. It shouldn't be happening! (btw I should mention that this text has been published via the publish button by users. No custom code has been anywhere near this published content!!)





Source Variation Page Text;
Be careful not to create the wrong impression with statements such as “He’s still on his coffee break” “she’s not in yet”. When a person is not available use statement such as "I am sorry Mr./Ms. He (use the persons name) is away from his/her desk at the moment, may I take a message”?


Target Variation Page Text;
Be careful not to create the wrong impression with statements such as “He’s still on his coffee break” “she’s not in yet”. When a person is not available use statement such as "I am sorry Mr./Ms. He (use the persons name) is away from his/her desk at the moment, may I take a message”?





Source Variation Page Markup;
<LI>Be careful not to create the wrong impression with statements such as “He’s still on his coffee break” “she’s not in yet”. When a person is not available use statement such as "<EM>I am sorry Mr./Ms. He (use the persons name) is away from his/her desk at the moment, may I take a message”?</EM></LI></UL>



Target Variation Page Markup;
<LI>Be careful not to create the wrong impression with statements such as “He’s still on his coffee break” “she’s not in yet”. When a person is not available use statement such as "<EM>I am sorry Mr./Ms. He (use the persons name) is away from his/her desk at the moment, may I take a message”?</EM></LI></UL>




From AllUserData table for the source;

<li>Be careful not to create the wrong impression with statements such as “He’s still on his coffee break” “she’s not in yet”. When a person is not available use statement such as "<em>I am sorry Mr./Ms. He (use the persons name) is away from his/her desk at the moment, may I take a message”?</em></li></ul>



From AllUserData table for the target;

<li>Be careful not to create the wrong impression with statements such as “He’s still on his coffee break” “she’s not in yet”. When a person is not available use statement such as "<em>I am sorry Mr./Ms. He (use the persons name) is away from his/her desk at the moment, may I take a message”?</em></li></ul>

Share: 

 

1 Answer Found

 
Answer #1    Answered By: Aakash Gavade     Answered On: May 17

OK. Well we tried to install the hotfix, but this failed with error “The detection failed, this can be due to a corrupt installation database.". The server guys were unable to solve this within their SLA and gave up.

However, I have discovered the reason for the odd characters  and the cure. It’s a tale of woe.

Management Summary; The variation  System didn’t match up with the correct content  type, but this was only an issue when we had more than one publishing  content field on a page…. Confused? Read on….

The client created their Source site  some months ago, and created several target  variations with several locales and languages. All seems to work, and published  content didn’t have any problems.

One large portion of the site had its own custom content type which amongst other things contained a page  content field of type Publishing HTML. This had always worked fine and no issues were suspected.

We recently amended the custom content type to have three extra Publishing HTML fields, and the content from the old field was migrated by hand into the three new fields. When this was published we started getting those odd  characters in the Target Variations, but the Source Variation text  looked fine.

I looked at the available content types on the Publishing Page Lists in our Target Variations. (Not easy – you have to go to ‘Manage Content and Structure’, then go to the pages list and click Edit Properties.) It turns out that the custom content type on the pages had never gone out to the variations. (Content type was based in the root site and should have been inherited but wasn’t). All the Target Variation Pages were based on Content Type ‘Page’. It staggers me that publish  had worked at all.

Even a brand new Turkish variation we created recently was based on Page, whereas the Source Variation was ‘customContentType’ (sic). I have heard about this issue with Content Types needing to be added manually before, but considering how variations  need the Source and Target Content Types to be the same I had thought it not an issue in this case.

So, I wrote some code to go through all the offending Publishing Page Lists and add the customContentType to them (not wanting to do several hundred lists by hand). They all have the right content type available to them now. ‘Page’ content type is still the default, but the correct  one is being referenced.

Now when we select ‘Update Variation’ or re-publish a page the content is coming through correctly.

I’m going to state again – I can’t believe the initial publish worked. Why did it work just because there was a single Publishing Content field rather than several? The Page content type in Target was significantly different to the content type in use on the Source Variation. But by working it stopped us seeing the obvious problem  when we changed things in Source. Wow. Glad to have that one sorted.

Why oh why doesn’t the correct content type go out to Variations? Even when a new variation is created from scratch!!

Now I just have to figure out why one of our servers doesn’t like hotfixes…

 
Didn't find what you were looking for? Find more on Published Content Encoded Incorrectly in Target Variations Or get search suggestion and latest updates.