You can not wire different types of string encodings together as the LabVIEW Unicode support never has been finalized to deal with such encoding mismatches and automagically do the right thing. You must make sure that all strings that you want to display Unicode are also set to be Unicode.

And bam it goes wrong, since the codepage 1254 byte codes are simply interpreted as a Unicode byte stream and that will surely result in something completely different, usually chances are pretty high that you will see at least some Chinese characters then. You then wire this byte stream to a control which is told to interpret the bytes as Unicode characters. If you then change the local language settings the bytes in this constant will stay the same but display different characters. Now if your constant where you enter the Turkish characters is not set to be Unicode explicitly too, the string entered will simply be the ANSI string using the current Windows codepage, hence the codepage 1254 characters. If your local language setting is set to Turkish, LabVIEW will actually support Turkish characters even without using Unicode since it uses the local region settings by default. It was considered a too hard problem to tackle at that time and abandoned but never removed from the code base. It means it has been added with minimal testing but never formalized and fully tested. What is your local language setting in Windows in these cases? LabVIEW Unicode support is not even experimental but at best alpha state.

Turkish character unicode