On Nov 6, 2014, at 10:59 PM, Michal Labedzki <michal.labedzki@xxxxxxxxx> wrote:
> Ability to change language is needed. But the real question is those
> names should be translated or not. For example KDE do that.
Do you mean that all the languages' names are translated into the *current* language?
If so, that's absolutely the wrong idea.
The right idea is to do what OS X and Windows do: show each language's name *in that language*.
I.e., don't translate *any* of the language names out of the language referred to by the name, not even into the current system language.
> KDE also
> provide two options: System language (Polish); No language (standard),
> where second one I assume is language in C++ code.
The KDE 4 on my Fedora 16 virtual machine provides, in the "Languages" tab of the "Country/Region & Language" pane of System Settings, a list of "available languages" and a list of "preferred languages". You can move languages from the first list into the second list. The languages in the second list are the ones used for applications; I infer from the pop-up tip for that list that, to pick a language for an application, KDE will check the first language in the list to see if there's a translation available and, if not, it'll check the second language in the list, etc., and fall back on US English if it finds no translations for any of the "preferred languages".
Where are the two options you mention offered?
> If names will be
> translated - how to provide user ability to change language when it
> may does not current language (for example English guy, that does not
> know Chinese). Or maybe flags solve this issue?
Doing what OS X and Windows do solve this issue. No matter *what* the current system language, English will be displayed as "English", French will be displayed as "Français", etc..
This may make life a bit harder for somebody who wants to set the system language to a language they can't read even to the extent of being able to recognize the language's own name, but that's probably rare enough that they can just use Google Translate.
However, it makes life easier for somebody confronted with a system configured to a language that they can't read who wants to switch the system to a language they *can* read (to the extent of being able to recognize the language's name in that language).
> Please not that in one thing Wireshark do translation better than KDE,
> because we can change translation without restart application
We can override the system language, or revert to the system language, without restarting the application.
A KDE application could also do that, if it were to offer its own language settings.
What KDE doesn't do - and what we don't do, either! - is dynamically change translation if the *system language* is changed.
Windows doesn't seem to do that, either, and the Apple App Store app, at least, doesn't do it on OS X.
Ideally:
1) the desktop environment would deliver to all applications a "system language changed" event;
2) the toolkit's event loop would handle as much of that event as possible, and would deliver an event to the application, if it asks to be notified of those changes, so that it could change whatever the toolkit can't handle automatically.
I don't know whether Windows, OS X, KDE, GNOME, or any other desktop environment bothers to notify applications of system language changes; if not, that's why you get those "you'll have to restart to get the new language" or "only applications started after this point will get the new language, applications already running won't change" dialogs.
>> ("Mis-named" because it should be something such as "System setting", to indicate what defines the language. I'll fix that.)
>
> Please do not do that. This will be a bug, because Wireshark does not
> support all possible system languages (for example Czech), so real
> language is not system, but Wireshark origin (English [in details:
> "C"]). "Auto" sounds better in this case.
"Auto" sounds wrong, as there's nothing "automatic" about it.
"Auto-detect" means that a user sits down in front of the computer and the computer automatically figures out what the language setting should be, *without* the system having been configured for their language and *without* the user having to set a language preference.
That's *not* what's happening here. What's happening here is that Wireshark is getting the system locale:
http://qt-project.org/doc/qt-4.8/qlocale.html#system
which is the locale that the person who set up the machine, or the user, has *manually* configured, and uses that, falling back on English if that's unavailable.
If you can come up with a name that does not contain the string "auto" anywhere in it and that accurately reflects the fallback to English for languages for which Wireshark has no translation, that'd be great. "Auto-Detect", however, is not the correct answer.
> Next question: currently Wiresharl fallback to "C" language. Should
> fallback to "English". As I remember translation from C to English is
> for tuning it.
The existence of a "C" locale is more than a bit bogus.
What *should* have happened when the C APIs were defined is that there should have APIs that perform actions such as formatting numbers in a specified locale (defaulting to the user's locale) and APIs that perform them in a locale-independent, explicitly specified and standardized, fashion.
For example, there should be routines that would print 1 1/4 as "1,25 in some locales and as "1.25"in others and routines that *always* print it as "1.25". If output is going to a user, use routines from the first set; if output is going to another program, which may be running in another, unknown locale, use routines from the second set.
The same applies to routines that raad numbers.
This is the same thing as <ctype.h> routines vs. g_ascii_ routines. And, in fact, GLib has g_ascii_strtod(), g_ascii_dtostr(), and g_ascii_formatd(), which *always* use "." as the decimal point in floating-point numbers.
So, if we're defaulting to the "C" locale in order not to print out floating-point numbers using "," as the decimal point, we should, instead:
find all the places where we should always be using "." as the decimal point (nothing displayed in the GUI should do this, and, arguably, the output from statistics taps in TShark shouldn't do this - do "LANG=C ./tshark ..." to force C-locale output;
make sure they are *NOT* using any of the printf routines, and make them, instead, use g_ascii_ routine;
stop defaulting to the "C" locale, or to any *other* explicitly-specified locale, set it to the "" locale.
> Additional question: Is English (*.ts) translation GB or US (or other)?
It's currently whatever the editors of wireshark_en.ts set it to.
There shouldn't *be* a wireshark_en.ts file. There should, instead, be wireshark_en_US.ts, wireshark_en_GB.ts, wireshark_en_CA.ts, wireshark_en_AU.ts, wireshark_en_NZ.ts, etc.. (And, yes, given that the UI will, in English, probably have the word "color"/"colour" in at least one menu item/toolbar item/message, there probably *will* be differences between wireshark_en_US.ts and the other wireshark_en_XX.ts files at some point. Whether the word "tire"/"tyre" ever appears in the UI is another matter, so whether there will be at least *three* different .ts files for English is also another matter. :-))
> By the way: Wireshark can be better than other software - it can have
> ability to change language in GUI. It is a feature.
It's a feature that works around incomplete or incorrect or absent translations. In the best of all possible worlds, the only people who would have a reason to use something other than the system language would be people testing translations or reproducing bugs and testing fixes, as everybody else would be happy with all applications using their preferred language setting (and people who use different languages just for the lulz).