What language comes back when qm file is loaded?

Here is a ponderance I have not tested. I was hoping someone here has danced this dance before.

Your application is written using American English. You load N language specific ts/qm files and allow the user to set the current translation to any of those languages.

Now, to keep it simple, you toss up one dialog with a label and a lineEdit. The label is dutifully translated to the correct language by the grace and beauty of Qt.

What language does the user "see" while typing into the line edit?
What languge is returned when you call text()?

Does setting the ts/qm file actually change the locale of the application such that a user sees their selected language while typing?

Hi

Quote:

---

Originally Posted by RolandHughes

What language does the user "see" while typing into the line edit?

---

Isn't it the language of the locale of system the application is run in?

Quote:

---

Originally Posted by RolandHughes

What languge is returned when you call text()?

---

AFAIK, QString is a unicode format. Each text returned from any Qt item is of a QString type. Unless you do not do any conversion, you can type in any language and everything should be correct.

Quote:

---

Originally Posted by RolandHughes

Does setting the ts/qm file actually change the locale of the application such that a user sees their selected language while typing?

---

you seem to mix two things here I think.
In terms of locale, you change locale of an application by calling QLocale::setDefault(QLocale::language,QLocale::cou ntry). You can simultaneously find a locale of your system by calling QLocale::system().name().
In terms of translation, I don't think ts/qm does any action. A programmer uses QTranslator class to load a translation to an application and make a phrase / message / text substituted by another text in the other language depending on which qm file has been loaded. A ts file is simply a pure text, a sort of map / XML file, that provides details of what is substituted by what. QM file is a release version of ts and used by QTranslator. If I am correct, the translation is the process of substitution of one text by another. A programmer may use Qlocale to find out which translation to use.

Quote:

---

Isn't it the language of the locale of system the application is run in?

---

I was hoping to get an actual answer from someone who has had to do it. If you are correct, and I hope you are not, in order to _see_ their chosen language rather than the language on their computer, one would have to change the language with QLocale which would not change the language for the external processes being communicated with via pipe or some other means.

Quote:

---

AFAIK, QString is a unicode format. Each text returned from any Qt item is of a QString type. Unless you do not do any conversion, you can type in any language and everything should be correct.
you seem to mix two things here I think.

---

I'm not mixing two things. I'm talking about multiple things. I'm talking about an application which must communicate with multiple completely independent services, some local, some on the Web, which will store to databases expecting English.

Having an application which displays a users chosen language for prompts and such via translation, but shows English because that is the locale of their machine would be incredibly tacky. Likewise, if you have fields like name and address which get entered in a language other than English yet has to be sent to processes and services which expect English, it is a significant problem. I can see no easy method of translating such things to English because there is no hard coded string to use with a qm file.

Yes, many databases will store unicode these days, but that also presents real problems.

Take, for example, a made up username like al-Ahammed
If one user enters it in English it looks as above. If another user enters it in Arabic it is a completely different set of unicode values. Likewise if another enters it using Kanji, etc. This presents significant query issues for technical support when they are trying to find and fix the account for one of the other languages.

Right now this is just a theoretical problem as I'm kicking around a system design which may or may not see the light of day, but this is a significant issue for anyone trying to develop an application for world wide use that doesn't want to force English down the throat of every user. I consider it horribly tacky for a system to allow a user to choose their application language, display all of the prompts, buttons, and help text in that language, then force them to enter English into any field which may be sent to a Web site or a database. There are a large number of users in the U.S. who leave their computers set to English but set specific applications to display their native tounge.

Once again, I would like to get an answer from someone that has actually written a multi-lingual application using Qt. Especially if that application MUST transmit English to some external system.

To be honest, I read your first post again and I would provide the same answers, with some exceptions perhaps. The post is confusing. The second post is even more confusing. I've done a lot of tests using different languages not exactly European / American but others as well and I am happy with the results. Obviously, in a multilingual application, you are almost forced to be aware of many things, much more than while coding application in English for English. Well, as you claimed for someone of much stronger expertise in this area, It's nothing more to say but good luck.

Quote:

---

What language does the user "see" while typing into the line edit?
What languge is returned when you call text()?

---

The translation files translate static text, such as your label, in your program to another language that a reader can understand. This has nothing at all to do with the characters (not language) that are entered into a text box by the operating system when a user types. These strings are returned to you by Qt as the Unicode encoding of the characters the user typed. The characters (actually glyphs) the user sees in the text box are exactly the characters the user would be expecting to see. If they are using a machine with the operating system set for a Turkish keyboard then when they press the lower case dotless i key they see a dotless i, "ı" and a Unicode dotless i character (U+0131) is returned in the text(). If they type the words "hoşça kal" into a text box that is what Qt will give you: it will not magically be translated to English as "goodbye", "bye-bye", "cheerio", "goodday", or even the French loan word "adieu" regardless of translation files. If that same user, on the same machine, switches the keyboard input to US English then types they will expect to see the English alphabet and glyphs when they type "goodbye". The user has the choice of how their keyboard functions and to force it can be downright counter-productive (think about typing a Hebrew sentence referring to a person with an English name).

If you have a need to store a native language version of a proper name and an Anglicised or romanised version of the name then you have two or more names, you need to store both, and the user will have to give you both as names are routinely romanised differently by different people. For example, someone with the Greek name "ΣτÎ*φανος" might be given the name in English of "Stephen" or "Steven" (or even use the phonetic "Stephanos"). The problem is not limited to two options: "Москва" (ru), "Moscow" (en), "Moscou" (fr), "Moskova" (tr) are all the same city. For some things, like countries, there are international standard codes that can used to partly ameliorate the problem. For similarly limited vocabularies lookup tables can be a workable solution. Some fuzzy matching techniques will also be useful picking up "Stephen" when given "Steven."

For system user names you can opt to limit the character set permitted in the name, use another identifier such email address that is similarly limited, allow native characters on the understanding that your technical support people are going to be native speakers, or use a meaningless identifier like an id number (1234).

Thank you for your reply. This is exactly the kind of catastrophe I was expecting.

The problem is even worse for computers sold in the Asian community in the United states. One of my favorite Chinese buffet type places had one on the bar. It would switch between English and Japanese when you bumped the mouse pointer into a certain region of the screen border. (I know how that sounds, but it really was a Chinese buffet owned by a Japanese family). I suspect there is a large number of these multi-lingual type setups at least in the United States.

Thanks again.
Roland