Display and i18n question: how to visualize and localize superscript and subscript characters in a string?

[napajejenunedk0]

1. Added:
   @QObject::tr( "m³" )@
   in a .cpp file.
2. Saved the file.
3. Closed the file.
4. Reopened the file.
   => The uppercase digit "3" is converted to "?": "m?".

Please, tell me the best way to visualize and localize superscript or subscript characters.
I know about the  and  HTML tags that can be used in a QLabel but the purpose is not only to visualize them but to localize them as well. For example someone would want to display "m³" as "cubic meters" translated into another language.

Regards

[giesbert]

Hi,

you should keep your source code clean.
If you are using characters outside ASCII 7-bit in source code, it might be read in a wrong manner, as that all belongs to codepages and encodings. Please use devnet search for other threads on encoding and codepages.

[napajejenunedk0]

http://www.qtcentre.org/threads/38541-QString-fromUtf8-problems-converting-micro-sign

Here Wysota mentions to change the file encoding to UTF-8. Also, the Qt Creator -> Text Editor file encoding should be set to UTF-8. Unfortunately, this doesn't work.
I agree that it is best to keep the code clean using ASCII 7-bit file encoding.

[goetz]

I know for sure that it does work because we do it all day here.

Just make sure, that you change the editor settings of Creator and convert the files.

• close all files in Creator
• change the editor settings to use UTF-8 as default
• quit Creator
• convert all files to UTF-8 (eg. by using "recode":http://directory.fsf.org/wiki/Recode)

in that order

Oh, and make sure, that you never ever touch the files with an editor that changes the encoding back to something insane.

[andre]

Volker and I always disagree on this one :-)
I'm with Gerolf: simply don't use non-ASCII in your source code, and do your proper strings in translation files using Qt Linguist or some other tool. Only semi-exception is from Qt Designer. You can enter non-ascii characters there and be fairly sure it will work on different machines of different developers with different encoding preference settings (that they may or not be aware of).

The root of all this evil is, that text files don't have an inherit encoding attached to them. That information somehow needs to be kept externally, or agreed on "by convention". So, there really no such thing as a "plain text file". That is a never ending cause of problems.

/me wishes that we (the world) could somehow agree on always including encoding information on some standard form in text files. And yes, I know it is probably impossible to do so in a way that won't screw with every existing application out there that works with "plain" text files, like compilers...

[goetz]

Right, Andre :) And I'm always getting slightly into a rant-mode with this :)

A simpler solution would be to agree on UTF-8 - com'on it's almost year 2012, we've landed on the moon, we'll fly to mars soon but we still shall stick to that stoneaged 7bit crap? That's ridiculous!

And yes, a switch to UTF-8 does work. Of course you have to instruct your co-workers. But it's not that much more difficult than instructing them to use 7 bit ASCII only.

Using English for the C++ texts is not always a way to go. You might have a team that targets only domestic use (it may want to translate it to English later on), that would have an additional translation step. You might have developers which are unable to build correct and understandable English texts (look at the forums!). These end up with an hard to understand English text being translated back to their native language - sound weird at best and at worst would lead to babelfish like native texts in the end.

And as a last one catch-all:
Machines have to adapt to man, not the otherwise round.

I'm plainly unwilling to restrict myself (and adding additional, unnecessary work!) only because of 40 year old artifacts that stinking lazy programmers are not willing to change to recent standards.