How to migrate an old panel (e.g 3.9) with pnl content to the current version?

[mmz]

Currently we are migrating our standard software from V3.9 to V3.14.

In some cases we uses our panels with xml content (there are no problems), but in others we need to run the panels with the pnl content (because of bar trend and other cases).

I tried the console feature:
-extend +config OUR_CONFIG_PATH -xmlConvert=XML -noBackup -p MY_RELATIVE_PATH -o
and after that
-extend +config OUR_CONFIG_PATH -xmlConvert=PNL -noBackup -p MY_RELATIVE_PATH -o
because I found no other way in the WinCC OA help file to do the migration easily.

It's transforming the file correctly and I can open it in Gedi, but some characters are not encoded correctly, like the ´ or the ü.
The issue for that is probably that the files format is ANSI and after the transformation it's UTF8.
That's what I wanted, but I thought it would transform the special character correctly too.

Is there a easy way to migrate/update these files correctly or not?
Or do I have to open each of those panels, and correct them manually?
I want to avoid the last step because of more than 300 files.

Thanks for every response in advance.

[mkoller]

Why do you think you have to change the old panels at all ?
Just open them in 3.14, no conversion needed.

[mmz]

Thank you for your answer.

There are more things that one to tell why we wanted to migrate our panels to the never version.
At last long story short we did overwritten some panels in SysMgm for our own porpuses.

On the 19.01.16 we got a Meeting with 2 employees from ETM. They told us, that ETM migrated their panels to UTF8.
So we questioned if we have to do it too, because we overwritten some of them and the consent was to do it too.
Additionaly we transformed the rest of our panels before a few weeks ago ( because we want utf8 fonts, it makes translation much more easier ).

Another fact would be, that we wanted to be consistent in all panels. At last in "V 13" (3.14) there is a DPI setting that isn't in "V 11" (3.9).

Nevertheless, I thought your command "-xmlConvert" would convert ANSI pnl-files in UTF8 xml-files.
No matter which special character it will be translated with: �.

[mkoller]

ok, I understand. It's not really the version you wanted to convert but mainly the languages used inside the panels (e.g. from the ISO languages to the UTF-8 languages).
To make things clear: there is no such thing as "ANSI pnl files". It's all about the LANGUAGES (and their encodings) used inside a panel file.
The encodings are used in the langStrings, so in fact a panel file contains different encodings when you have e.g. de_AT.iso88591 and also zh_TW.big5 in your project.
No matter which languages a panel contains, the UI should be able to read them correctly and to also deal correctly with the encodings used inside.
The only problem which can probably happen is when you have hardcoded strings inside scripts in that panel - depending on the version the panel was created with.
In 3.9 a script only contains ASCII chars, from V12 on the scripts are encoded in UTF-8.
Where are the characters you encounter the problem ? Inside a script or in a langString ?
It would be best to send such a panel to our support crew so we can analyze what's going on.

[mmz]

Files are always saved in a special format (ANSI, ISO, OEM, UTF8 ...) so are pnl files.

For the last years we had e.g for english -> iso88591 and for chinese -> sjis in the panel files.
Would the files itself been saved in utf8 (they weren't) we wouldn't have this problem, but they were saved in iso... (depending on the languages codepage), because the fileserver and logically DB itself were set up to iso...

So to make things right with 3.14, we set up a new server/project with utf8.
With this we can now handle all translations in one file, not caring about BOM (hope I guess right) or the codepage, because it's utf8.

My problem is solved so far, because I used your xmlConvert and replacing the special characters in GEDI.
Glad that there weren't so many as I thought in the beginning.

I think that I had the problem, because i wrote a script, which migrated all e.g. LANG:1 to LANG:10001 ( so from iso to utf8 ), not thinking about the special characters in the panel files too.

But answering your questions, because it could be relevant for other users:
I discovered the problem not only in the script part from a panel.

e.g. a simple text label (not translated yet)

0 5
LANG:10001 15 Translate DP?s
LANG:10004 16 Translate DP?s
LANG:10010 16 Translate DP?s
LANG:10011 16 Translate DP?s
LANG:10000 16 Translate DP?s
4 195
"LINE9"

But like I wrote above, I think this error occured because I updated the files with my script to LANG:10001. So like you said, GEDI takes that codepage and encodes it, not knowing in which file format the file itself is saved.
Opening the file with PsPad or Notepad++ I got:

0 5
LANG:10001 15 Translate DP´s
LANG:10004 16 Translate DP´s
LANG:10010 16 Translate DP´s
LANG:10011 16 Translate DP´s
LANG:10000 16 Translate DP´s
4 195
"LINE9"

because PsPad and Notepad recognizes, that the files saved as iso88591 and not utf8.

utf8 needs a  before ´ for right encoding.

Thanks to your post above I was able to understand and solve my problem.
Thanks and regards.

[mkoller]

I have to correct you.
"Files are always saved in a special format (ANSI, ISO, OEM, UTF8 ...) so are pnl files."
Files are just a stream of bytes. They contain what the application puts into them. A panel file is written with DIFFERENT encodings depending on what it currently writes,
e.g. as said before, a langString can contain multiple languages each using a different encoding, so in fact each line of a langString is encoded differently.

Your assumption that a panel file is written like a normal text file does not hold here.
You can also view it as a kind of "binary" file, which happens to be usable close to a "normal" text file - but only close to.

I don't know what your script did, but what would be wrong is to simply change a language number (e.g. from 1 -> 10001) without taking care about the encoding
and the number of bytes for the encoding (the langString format tells the number to bytes which follow).
As you have already seen, all german umlauts in ISO-88591 are encoded in 1 byte but use 2 bytes in UTF8.

Viewing any panel file with an arbitrary text editor will fail when the panel file contains multiple encodings.

[mmz]

Ah yeah you are right, sorry for that.
Thank you for taking me back to school I do appreciate that.
Funnily engough I thought on what you told me above in my script, reading and writing the file binary.

But always using the editor to check that encoding in general thought me to turn of my brain :dry:
because they mostly uses the right encoding.