Encoding hair-puller

zyggie04

Here's the rundown.
Using Teamsite 6.1 (on Win2000 server), requirements of the projected system calls for french language (ie. accented) content input. As per previous encoding situations (albeit in the "pure" XML world) as well as from reading posts around here, I've selected ISO-8859-1 as the appropriate encoding scheme.

1. The datacapture.cfg holds the <?xml version="1.0" encoding="ISO-8859-1"?> directive.
2. at DCR creation time, the user types in accented stuff in input fields (text fields, textareas, no VF), and eventually saves it to an (autonamed) DCR.
3. The DCR inner xml shows double-byte material in place of the accented input, and also carries the encoding directive as UTF-8 (I have no control over that, yet).
4. at page generation time, the PTL (also defined as ISO-8859-1) properly generates an HTML page, that displays as intended in the browser (accents show as accents, all is well).

the plot thickens...
5 the user returns and EDITS THE EXISTING DCR.
6. the pre-existing data shows up in the input fields as GARBAGE (ie every 'é' shows as 'é' - that's what was held in the DCR, after all..)
7. the user adds text (with, say, some more accents), saves the DCR, regenerates the page, BANG! previously existing material will show - in the HTML - as garbled (é = é), newly entered material shows ok.

The questions that rob me of my sleep:
- should - somehow - the DCR hold the "finished" product? Should the encoding interactions end up with the 'é' in the DCR ? so all subsequent actions follow through? in which case, what am I missing ? (must be something big, right?)
- am I on the right track but missing the mandatory "customized perl module" that will chew on the DCR's between the user save and any other step? or maybe between the user-edit-request event and DCT edit-time?

any suggestions as to possible subsequent troubleshooting strategies would be greatly appreciated.

btw, I did attempt to modify the script iwpt_encoding.ipl to return ISO-8859-1; no success.

Gazillion thanks,
Mike

Frederik

i can only say this :

note: we're doing a ±10 language site for European countries. Our entire "pipeline" is UTF-8. (almost) no problems. TS 5.5.2 sp4 on Solaris.

I think the weirdness is mostly with your step 5, 6. Users that reopen a DCR should see it with all correct content.

So you should question: what browser (on client machine) is used, and is that browser declared compatible with your TS version (every SP counts here!). Has the browser been configured for a specific encoding, or is it set to "auto".

We had one similar case of a user saying that his DCR opened with strange chars. He switched to Java interface (which is end-of-life with TS 5.5). But I think that if we had a closer look at his pc, we would have found a local error in the browser.

Btw, the (1) thing is irrelevant, I believe. The encoding of the DCT is just that. The DCT is an xml file, so it has to specify its own encoding. AFAIK it doesn't influence the data recorded at all.

grts, Fred