Primäre Fremdsprache oder Region erkennen, obwohl Englisch die eingestelle Default Sprache ist?

[buhtz]

Hi,
ich frage mich, ob es mit dem "locale" System oder etwas ähnlichem möglich ist, bei einem GNU/Linux System zu erkennen bzw. Hinweise darauf zu finden, dass das System in einer Region läuft, in der Englisch eigentlich nicht die Hauptsprache ist.

Hintergrund meiner Frage ist, dass es in vielen Regionen (z.B. Indien, China, Nordeuropa) relativ weit verbreitet zu sein scheint, dass die Leute die Oberfläche Ihrer Geräte auf Englisch stellen. Das kann Gewohnheit sein, oder auch daran liegen, dass die Übersetzungen der einzelnen Anwendungen zu grottig sind.
Weiterhin vermute ich, dass solche Anwender:innen nicht bei jeder Ihrer Anwendungen sich durch die Einstellungen wühlen, um diese evtl. dort auf ihre Hauptsprache zu stellen.

Das Ergebnis ist, dass es den Anwender:innen unbekannt bleibt, dass ihre Anwendungen, eigentlich eine entsprechende und vielleicht gute Übersetzung in ihrer Hauptsprache anbietet. Die Anwendungen wählen ja per default die Systemsprache (Englisch).

Wenn ich nun als Entwickler so einer Anwendung im System Hinweise finden könnte, dass die eingestellte Systemsprache vielleicht doch nicht die Hauptsprache ist, könnte ich die Anwender:innen aktiv (via Dialog) darauf hinweisen, dass Sie doch mal im Sprachmenü der Anwendung nachschauen sollten.

Meine Anwendung (backintime) bietet 46 Sprachen, einige auch exotisch. Ich möchte erreichen, dass die Arbeit der Übersetzenden eben auch Früchte trägt und nicht verborgen bleibt. Die Arbeit wäre ja fast umsonst.

Konnte man das jetzt verstehen?

Alternativ könnte ich auch jedem der die Anwendung in Englisch nutzt, auf die Sprachvielfalt hinweisen. Aber das wäre mir zu breit gestreut und würde 99% der Leute nerven und wäre für diese auch irrelevant.

[hikaru]

Dein Ansinnen in allen Ehren, aber als Anwender, der einige seiner Systeme mitten in Deutschland auf Englisch eingestellt hat:
Lass es bitte! Es ist volle Absicht, Systeme außerhalb Englischsprachiger Gebiete auf Englisch einzustellen - hauptsächlich deshalb, damit sich das System möglichst "standardmäßig" verhält.
Ich möchte nicht, dass mich jedes einzelne meiner 1000 Programme mit einem Dialog nervt, der mich darauf hinweist, dass es ja doch eine gute Lokalisierung zu haben meint - eine Einschätzung die ich teilen mag oder auch nicht.

[GregorS]

Ich möchte nicht, dass mich jedes einzelne meiner 1000 Programme ...

Es geht gerade nicht um eines Deiner 1000 Programme (hast Du die echt gezählt?), sondern um eine Anwendung, die man wie viele seiner Programme bewusst installiert/nutzt. Ich halte das Ansinnen des OPs für gut.

[heisenberg]

Mir geht das ähnlich wie Hikaru. Ich will keine unnützen Dialoge. So etwas geht mir als User ganz schnell auf den Senkel.

Was ich noch akzeptabel fände, wäre ein Willkommensdialog beim ersten Start, wo so eine Info mit dabei wäre.

Alternative: Es gibt einen Meldungsbereich, wo das angezeigt wird. Oder wie wäre es im Hilfe -> About Bereich?

[buhtz]

Erstmal Danke für eure Anmerkungen und Gedanken.

Ich will den User auch nicht nerven; nicht nur so wenig wie möglich, sondern eigentlich gar nicht. Kein Willkommens-Dialog, kein Erste-Tips-Fenster oder banner-artige Einblendungen oder Infos irgendwo im Hauptfenster.

Ein modaler Dialog (also Zwangsdialog) für eine Untergruppe der Nutzer, die mit hoher Wahrscheinlichkeit nicht Ihre Primärsprache als Default im OS hinterlegt haben, wäre evtl. ein akzeptabler Kompromiss.

Die "guten Gründe" für Sprach-Einstellungen sind vielfältig und nicht nur auf Englisch begrenzt. Ich bin seit Monaten im Kontakt mit diversen sprachbezogenen Communities zu diesen Themen. Im Raum China ist man es gewöhnt, dass GUIs derart grottig schlecht übersetzt sind, dass deswegen hier häufig auf Englisch wechselt. In Norwegen und Finnland sind die Übersetzungen ebenfalls häufig von minderer Qualität.

Aktuell ist der "Setup Language" dialog als Menü-Punkt in einem der Menüs der Hauptmenü-Zeile untergebracht (Bild). Da es 46 Sprachen sind, kann ich diese nicht als eigenen Menüpunkte in der Menübar unterbringen. So wären sie präsenter bzw. man guckt mal eben schnell die Liste durch.

Es wird wohl keine gute Lösung dafür geben. Da ich keine Telemetrie habe und auch nicht haben werde, kann ich auch nur um Dunkeln stochern und Vermutungen anstellen, wie viele meiner User das überhaupt betrifft. Soweit ich sehe erhebt popcon auch keine Regions- oder Sprachdaten?

Vielleicht ist ein (nicht modaler) kurzer Text in der Statusbar oder einem Info-Bereich doch der beste Kompromiss.

[dakuan]

Es ist volle Absicht, Systeme außerhalb Englischsprachiger Gebiete auf Englisch einzustellen...

Das kann ich bestätigen. Ich hatte früher mit Leuten zu tun, die mindestens einen ihrer Rechner auf japanisch, chinesisch oder kyrillisch fest eingestellt hatten. Kommt in einer Hafenstadt öfters vor.

[hikaru]

Es geht gerade nicht um eines Deiner 1000 Programme (hast Du die echt gezählt?),

Code: Alles auswählen

$ ls -l /usr/bin/
Display all 1167 possibilities? (y or n)

sondern um eine Anwendung, die man wie viele seiner Programme bewusst installiert/nutzt.

Alle diese Programmeakete sind bewusst installiert. Das System habe ich als Minimalsystem per debootstrap installiert, und dann ohne Recommends und Suggests genau das nachinstalliert, was ich brauche.
Das bedeutet nicht, dass ich alle 1000 Programme bewusst benutze, aber die notwendigen Abhängigkeiten führten dann zu diesem Zustand.

Ich halte das Ansinnen des OPs für gut.

Ich auch - im ersten Moment. Aber wie so oft, wäre hier "gut gedacht" das Gegenteil von "gut gemacht".
Man sollte dem User einfach zugestehen, dass er selbst am besten weiß, warum er sein System so konfiguriert, wie er es tut. Wir sind ja hier nicht (alle) bei Gnome.

[Meillo]

Dein Ansinnen in allen Ehren, aber als Anwender, der einige seiner Systeme mitten in Deutschland auf Englisch eingestellt hat:
Lass es bitte! Es ist volle Absicht, Systeme außerhalb Englischsprachiger Gebiete auf Englisch einzustellen - hauptsächlich deshalb, damit sich das System möglichst "standardmäßig" verhält.
Ich möchte nicht, dass mich jedes einzelne meiner 1000 Programme mit einem Dialog nervt, der mich darauf hinweist, dass es ja doch eine gute Lokalisierung zu haben meint - eine Einschätzung die ich teilen mag oder auch nicht.

Das sehe ich auch so. Ich moechte, dass sich mein System so verhaelt wie ich es per Systemeinstellungen konfiguriere und nicht meint, es muesste sich die Freiheit nehmen, irgendwas besser wissen zu wollen.

(Nachtrag: Das ist doch gerade das Problem bei Windows: Jedes Programm macht die Dinge auf die eigene Weise. Und das Schoene bei einer GNU/Linux-Distribution ist die Einheitlichkeit: systemweite Spracheinstellungen, einheitliches Loggingsystem, einheitliche Datenablage im Dateisystem, einheitliches Hilfesystem, usw. Es skaliert nur wenn man die User lehrt, dieses Dinge zu verstehen, und die Entwickler lehrt, diese Dinge zu nutzen, und nicht indem man sie aufbricht.)


Aber ich habe einen Vorschlag zu machen: Wenn du so eine Hilfefunktion fuer Erstanwender, Tipps fuer den Einstieg oder so eh schon hast, wie es bei einigen grafischen Programmen ueblich ist, dann kannst du dort den Hinweis unterbringen, dass man die GUI-Sprache umstellen kann. Mehr als das wuerde ich nicht machen.

Bei grafischen Anwendungen und Spielen schaue ich bei Bedarf nach, ob es ein deutsches Sprachpaket gibt oder man die Programmsprache in den Einstellungen umstellen kann.


Der Vollstaendigkeit halber noch eine technische Antwort auf deine Frage: Man kann einfach die verschiedenen Eintraege im Locale (d.h. konkret die Umgebungsvariablen mit Namen LC_*) durchgehen und schauen, was da fuer Sprachen auftauchen. Hier beispielsweise ein System von mir mit deutscher Zeit:

Code: Alles auswählen

:-/ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME=de_DE.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Andere LC_-Settings wuerden fuer mich auf Deutsch auch mehr Sinn machen als auf Englisch, bloss waren die bislang noch nicht relevant genug, um sie umzustellen. Als Systemsprache und vor allem fuer die Fehlermeldungen bevorzuge ich eindeutlg Englisch.

Allerdings werden unerfahrenere User viel eher die Spracheinstellung in der GUI finden als ihre Locale-Settings spezifisch anzupassen, was die Sache recht nutzlos macht.

(Auch wenn du dieses Wissen nicht fuer deine urspruengliche Idee nutzen solltest, kann man ja durchaus sein Wissen erweitern. )

[MSfree]

...das Schoene bei einer GNU/Linux-Distribution ist die Einheitlichkeit: systemweite Spracheinstellungen, einheitliches Loggingsystem, einheitliche Datenablage im Dateisystem, einheitliches Hilfesystem, usw.

Bei der Sprache bin ich mir nicht sicher, halten sich Firefox und Thunderbird wirklich an die systemweite Einstellung?

Das Logging ist aber unter Linux nicht einheitlich:
/var/log/syslog oder doch
/var/log/messages oder doch
/var/log/journal/... oder doch
/var/log/apache oder doch
/var/log/squid oder doch
/var/log/samba oder doch
~/.xsession-errors oder doch
~/.cache/lxsession/LXDE/run.log ...

Auch das Hilfesystem unterscheidet zwischen man-Pages und in GUI-Programmen eingebaute Hilfesysteme. Früher gab noch die info-Pages und ein Blick in /usr/share/doc kann auch nicht schaden.

Grundsätzlich sollte aber ein Programm sich an die systemweite Spracheinstellung halten, die sich via $LANGUAGE ermittlen läßt. Wenn das Programm zusätzlich eine abweichende Einstellung ermöglicht, ist das OK. Aber über eine Geolokalisation zu gehen, ist die schlechteste Möglichkeit. Ein Koreaner, der sich gerade mit seinem Laptop in Deutschland aufhält, wird mit der dann erzwungenen deutschen GUI sicher nicht glücklich.

Ich sehe gearede, du hattest $LANG erwähnt. Also auch hier keine Einheitlichkeit.

[Meillo]

@MSfree: Ich meine natuerlich Unix-Systeme und GNU/Linux-Distributionen wie sie mal waren bevor immer mehr selbstgefaelligen Entwickler groesserer Software-Suites (Desktop-Environments, Office, Webbrowser, etc.) Einzug gehalten haben, um sich einen Dreck um einheitliche Gesamtsysteme zu scheren, sondern ihren Horizont an den Grenzen des eigenen Programms enden zu lassen. Selbst fuer Distributionen ist es nicht mehr leistbar, dieses Flickenwerk zu vereinheitlichen. Die Folge ist, dass sowohl die User als auch die neuen Entwickler die einheitlichen Konzepte des Gesamtsystems nicht mehr selbst erleben und auch anfangen, auf eigene ``tolle'' Ideen zu kommen, statt das groessere Ganze zu verstehen und sich einzufuegen. So zerfasert es immer mehr. Am Ende haben alle Nachteile, weil alle nur an ihre kurzfristigen Eigeninteressen denken, anstatt erstmal verstehen zu lernen.

Ach, ich rege mich nur wieder auf ...

[Meillo]

Grundsätzlich sollte aber ein Programm sich an die systemweite Spracheinstellung halten, die sich via $LANGUAGE ermittlen läßt. [...]

Ich sehe gearede, du hattest $LANG erwähnt.

Soweit ich sehe wird $LANGUAGE nur von GNU verwendet:

LC_MESSAGES
changes the language messages are displayed in and
what an affirmative or negative answer looks like.
[...] The GNU gettext family of
functions also obey the environment variable LAN‐
GUAGE [...]

Auf meinen Debian-Systemen ist $LANGUAGE normalerweise leer. Unter FreeBSD ist es gar nicht gesetzt (was die Vermutung erhaertet, dass es eine GNU-Erfindung ist).

$LANG dagegen ist der generische Fallback wenn keine LC_*-Variablen gesetzt sind:

If the second argument to setlocale(3) is empty string,
"", for the default locale, it is determined using the
following steps:

1. If there is a non-null environment variable
LC_ALL, the value of LC_ALL is used.

2. If an environment variable with the same name as
one of the categories above exists and is non-
null, its value is used for that category.

3. If there is a non-null environment variable LANG,
the value of LANG is used.

POSIX sieht das auch so:

The determination of the name of the new locale for the specified category depends on the value of the associated environment variables, LC_* and LANG

LANG
This variable shall determine the locale category for native language, local customs, and coded character set in the absence of the LC_ALL and other LC_* (LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_NUMERIC, LC_TIME) environment variables. This can be used by applications to determine the language to use for error messages and instructions, collating sequences, date formats, and so on.

$LANGUAGE wird in POSIX nicht erwaehnt.

$LANG ist sicherlich aelter als $LC_* und ist daher der Kompatibilitaetsfallback.

[MSfree]

Soweit ich sehe wird $LANGUAGE nur von GNU verwendet:

Keine Ahnung. Ich hatte nur schnell mal export im Terminal ausgeführt und dort

Code: Alles auswählen

declare -x LANG="en_US:UTF-8"
declare -x LANGUAGE="en_US:en"

gesehen.
LC_... habe ich bei mir gar keine gesetzt.

$LANG dagegen ist der generische Fallback wenn keine LC_*-Variablen gesetzt sind:
$LANG ist sicherlich aelter als $LC_* und ist daher der Kompatibilitaetsfallback.

Es zeigt sich aber auch hier, daß es keinen einheitlichen Weg zu geben scheint, die systemweite Spracheinstellung zu ermitteln. Man muß also $LANG, &LANGUAGE und $LC_* abklappern und hoffen, daß etwas sinnvolles dabei rauskommt.

Mich wundert es nicht, daß viele Programmierer sich darauf nicht verlassen wollen und lieber etwas eigenes basteln.

[Meillo]

Es zeigt sich aber auch hier, daß es keinen einheitlichen Weg zu geben scheint, die systemweite Spracheinstellung zu ermitteln. Man muß also $LANG, &LANGUAGE und $LC_* abklappern und hoffen, daß etwas sinnvolles dabei rauskommt.

Den einheitlichen Weg gibt es nur deshalb nicht, weil die Entwickler sich nicht dem anpassen was von POSIX definiert ist. POSIX war ja gerade das Bestreben, die Unterschiede zwischen System V und BSD und den sonstigen kommerziellen UNIX-Varianten einzufangen und zu vereinheitlichen. Warum muss dann GNU $LANGUAGE verwenden statt das bereits existierende und standardisierte $LANG? Das ist was ich nicht verstehe.

Mich wundert es nicht, daß viele Programmierer sich darauf nicht verlassen wollen und lieber etwas eigenes basteln.

Ich behaupte, sie basteln vor allem deshalb immer wieder etwas Neues, weil sie das Alte nicht kennen oder nicht verstehen oder weil sie meinen, sie koennten es besser. Also Unwissenheit, NIH und https://xkcd.com/927/

[buhtz]

Danke nochmal für eure Hinweise und Anmerkungen.

wie so oft, wäre hier "gut gedacht" das Gegenteil von "gut gemacht".

Deswegen denke ich ja vorher, mit euch zusammen.

Man sollte dem User einfach zugestehen, dass er selbst am besten weiß, warum er sein System so konfiguriert, wie er es tut.

Davon gehe ich aus. Aber der Grund ist nicht immer ein guter Grund, sondern in vielen Fällen auch einfach Frustration und Gewöhnung daran, dass Übersetzungen in die eigenen Primärsprache von so schlechter Qualität sind, dass man es gar nicht mehr versucht.

Ich möchte noch einmal klarstellen, dass meine Anwendung sich per default die Spracheinstellung des Systems holt und auch daran hält. Der User hat in einem Einstellungsdialog die Sprache der Oberfläche zu ändern und damit die Systemsprache des OS zu ignorieren.
Es geht mir nicht darum, Abseits der Systemsprache eine zweite Sprache zu identifizieren und diese dann automatisch einzustellen. Das ist natürlich nicht nur nicht möglich, sondern auch dem User gegenüber unmöglich. Es geht mir darum, Hinweise darauf zu finden, dass ein User evtl. nicht seine Primärsprache als Systemsprache verwendet. "Hinweis" ist nie fest und sicher. In dem Fall könnte ich den User vorsichtig darauf hinweise, auf eine möglichst wenig nervende Weise, dass er doch mal ins Sprachmenü schauen sollte, ob eine der 46 angebotenen Optionen doch seinem Geschmack entspricht. Immerhin wird dort auch Esperanto, Occidental und weitere regions-unabhängige Sprachen angeboten. Ich warte eigentlich nur noch auf Klingonisch.

Ich werde mal weiter darüber nachdenken.
Technisch erscheint mir der Abgleich der "locale" Variablen am wenigsten unsinnig zu sein.

[MSfree]

Es geht mir darum, Hinweise darauf zu finden, dass ein User evtl. nicht seine Primärsprache als Systemsprache verwendet.

Den Standort kannst du einigermassen genau über geoiplookup aus geoip-bin feststellen. Das liefert dir aber (nicht immer zuverlässig) nur Stadt und Land. Welche Sprache dort gesprochen wird, kannst du darüber nicht feststellen.

Ob es Datenbanken gibt, die aus Ort/Land eine oder mehrere Sprachen extrahieren können, weiß ich nicht. Mehrere Sprachen deshalb, weil z.B.

• in Bern Deutsch und Französisch
• in Dublin Irisch und Englisch
• in Flensburg Deutsch und Dänisch
• in Helsnki Finnisch und Schwedisch
• in Johannesburg Englisch, Afrikaans und mindestens 9 afrikanische Sprachen
• in Mailand Deutsch und Italienisch
• ...

gesprochen werden.

Es wäre aber nur eine Fleißarbeit, aus den 193 Links der Liste alle Staaten die Amtssprachen zu extrahieren und in einer eigenen Datei/Datenbank deinem Programm mitzugeben.

[buhtz]

Das mit der Geolocation war mehr so ins Unreine gedacht und Worst-Case. Es ist nicht praktikabel, da Staat/Region nicht gleich Sprache bedeutet, auch wenn man das aus deutscher Perspektive häufig nicht nachvollziehen kann.

Auch wenn ich die IP oder Koordinaten nicht versenden würde, rollen sich bei mir schon alleine durch die Erhebung/Messung dieser Parameter die Fußnägel hoch. Das geht einfach nicht, ist zu privat und fühlt sich einfach nicht richtig an; ganz unabhängig von der Praktikabilität.

[Meillo]

Wie wuerde man das mit der IP-Adresse denn technisch bei einer lokal laufenden Anwendung machen? Da muesste man doch eine Verbindung ins Internet aufmachen, um die externe IP-Adresse erfahren zu koennen.

[MSfree]

Das mit der Geolocation war mehr so ins Unreine gedacht und Worst-Case. Es ist nicht praktikabel, da Staat/Region nicht gleich Sprache bedeutet.

Du hast wohl nur die Hälfte von dem gelesen, was ich geschrieben habe.

Auch wenn ich die IP oder Koordinaten nicht versenden würde, rollen sich bei mir schon alleine durch die Erhebung/Messung dieser Parameter die Fußnägel hoch.

Und nun setz mal deinen Aluhut wieder ab. Die IP-Adresse, die abgefragt werden müßte, ist die deines Routers, die Info bleibt also im LAN. Auch das geoiplookup ist eine rein lokale Abfrage, dazu braucht man nichtmal Internet.

Das geht einfach nicht, ist zu privat und fühlt sich einfach nicht richtig an;

Doch, das geht, sogar ganz ohne aluhutmässiger Bedenken.

[Meillo]

Die IP-Adresse, die abgefragt werden müßte, ist die deines Routers, die Info bleibt also im LAN.

Mein Router hat nach innen noch eine lokale Adresse und nach aussen eine externe Adresse. Wenn ich seine externe Adresse erfahren will, dann muss ich doch ein Paket ueber sie verschicken und dieses wird dann schon nach aussen uebermittelt, oder?

Solange ich nicht auf dem Router selbst bin, sondern nur vom LAN aus Pakete an ihn schicken kann, kann ich seine externe Adresse doch nur dann erfahren wenn ich ein Paket ueber sie routen lasse ... was ich aber nicht will, weil ich dann ja schon mit dem Internet kommunizieren wuerde ...

[MSfree]

Mein Router hat nach innen noch eine lokale Adresse und nach aussen eine externe Adresse. Wenn ich seine externe Adresse erfahren will, dann muss ich doch ein Paket ueber sie verschicken und dieses wird dann schon nach aussen uebermittelt, oder?

Dann macht man halt ein traceroute zu ftp.debian.org und nimmt die erste IP-Adresse, die nicht aus einem privaten IP-Bereich stammt. Welche datenschutzrechtlichen Bedenken soll es denn bei so einem traceroute geben? Eine andere Möglichkeit, den Ort festzustellen, liefern nur GNSS und Mobilfunk, was einen entsprechenden Empfänger bedingen würde.

Ich sehe in so einer IP-Abfrage jedenfalls überhaupt kein Problem. Das würde ja in dem Programm nur bei Bedarf vom Benutzer angestoßen, und vor den Knopf, der das anstößt, kann man eine Funktionserklärung für Aluhüte stellen:

Achtung, wenn sie diesen Knopf drücken, kann eine passende Sprache für ihre Region ermittelt werden. Hierzu ist eine Internetverbindung nötig.

[debianoli]

Firefox zB macht doch eine recht genaue Ortsbestimmung, sofern man die nicht blockt.

Meines Wissens nach ist die auch unabhängig vom OS

[buhtz]

Und nun setz mal deinen Aluhut wieder ab. Die IP-Adresse, die abgefragt werden müßte, ist die deines Routers, die Info bleibt also im LAN. Auch das geoiplookup ist eine rein lokale Abfrage, dazu braucht man nichtmal Internet.

Das geht einfach nicht, ist zu privat und fühlt sich einfach nicht richtig an;

Doch, das geht, sogar ganz ohne aluhutmässiger Bedenken.

"Es geht" bezog sich nicht auf das technisch Machbare, sondern auf Prinzip und Anstand. Darüber lässt sich bekanntlich streiten.

"Aluhut" grenzt schon an Beleidigung.

Ich denke IMHO in etwas größeren Rahmen. Stell dir mal einen technisch unbedarfteren User vor. Der bekommt von seiner Anwendung die Meldung, dass er sich in einer bestimmten Region befindet und deswegen z.B. die Spracheinstellungen mal checken sollte. Die Anwendung kennt meinen Ort. Das kann einigen Menschen schon zu weit gehen und Unsicherheit und Angst schüren. Ihne fehlt die Kompetenz oder auch einfach die Zeit und Nerven, die Anwendung oder deren Doku dahingehend zu prüfen, wie die Ortsinfo erlangt wurde und wie diese weiterverwendet wird.

Ich sehe in so einer IP-Abfrage jedenfalls überhaupt kein Problem. Das würde ja in dem Programm nur bei Bedarf vom Benutzer angestoßen, und vor den Knopf, der das anstößt,...

Nein, so ist das nicht gedacht. Dann würde ich ja jeden User mit einer Meldung (Knopf drücken ja/nein) nerven. Das geht definitiv nicht.
Ich will ja vorab die Untergruppe der User haben, die mutmaßlich nicht ihre Primärsprache als Systemsprache verwenden und alle anderen in
Ruhe lassen.

Aber lassen wir das jetzt mal mit der Geo-IP. Abgesehen von den "gefühlsmäßigen" Implikationen, ist es einfach nicht praktikabel, weil man von Region nicht auf Sprache schließen kann.

[MSfree]

Stell dir mal einen technisch unbedarfteren User vor. Der bekommt von seiner Anwendung die Meldung, dass er sich in einer bestimmten Region befindet...

Willst du dieses Feature nun einbauen, daß es immer und ständig dem, Benutzer auf den Geist geht? Oder willst du das als mehr oder weniger einmalige Sache einbauen, die der Benutzer bei Bedarf und auf eigene Veranlassung betätigen kann?

Wenn ersteres: dann vergiß es!
Wenn zweiteres, dann ist eine Ortsbestimmung via IP-Adresse sicherlich kein Problem.

Die Anwendung kennt meinen Ort. Das kann einigen Menschen schon zu weit gehen und Unsicherheit und Angst schüren.

Nur, wenn man es nicht erklärt.

Ein Anwendung, die in meinem $HOME in seiner Konfigurationsdatei die Spracheinstellung abgelegt hat, kennt den Ort nicht. Der Ort wird ja nur als Zwischenergebnis genutzt, um eine oder mehrere Sprachen vorzuschlagen. Der Ort braucht nicht gespeichert zu werden und das kann man dem Nutzer auch ganz einfach auf der GUI erklären.

Solange der Benutzer hier keine Aktion auslöst, wird weder das Internet befragt, noch ein Ort ermittelt und gespeichert wird der sowieso nicht.

Ein wenig mitdenken, wie man dem Nutzer die Bedenken nehmen kann, hätte ich dir schon zugetraut.

Aber lassen wir das jetzt mal mit der Geo-IP. Abgesehen von den "gefühlsmäßigen" Implikationen, ist es einfach nicht praktikabel, weil man von Region nicht auf Sprache schließen kann.

Doch, das könnte man. Wie, habe ich oben erläutert, aber das hast du geflissentlich ignoriert.

[buhtz]

Es geht nicht darum, ob ich die Ortsbestimmung für unbedenklich halte.

Nur, wenn man es nicht erklärt.

Aber ich will es ja nicht erklären bzw. dem User eine Erklärung ersparen.

Ein wenig mitdenken, wie man dem Nutzer die Bedenken nehmen kann, hätte ich dir schon zugetraut.

Nochmal, ich denke scheinbar größer. "Bedenken", soll der User ja gar nicht erst entwickeln.

Aber lassen wir das jetzt mal mit der Geo-IP. Abgesehen von den "gefühlsmäßigen" Implikationen, ist es einfach nicht praktikabel, weil man von Region nicht auf Sprache schließen kann.

Doch, das könnte man. Wie, habe ich oben erläutert, aber das hast du geflissentlich ignoriert.

Hab ich nicht ignoriert, sondern eben als nicht praktikabel abgelegt. Wenn ich dich richtig verstanden habe, regst du an eine Liste von Ländern mit einer Liste von Sprachen zu matchen. Das spiegelt nicht die Realität der Menschen und verschiedenen Regionen der Welt wieder. Welche Sprache gehört zur Schweiz, zu Norwegen, China, ...? Nicht alle Länder sind monolingual und selbst, solche die es glauben zu sein (z.B. Deutschland), sind es nicht.

Das Ergebnis eines Länder-Sprachen-Matches ist viel zu schwammig.

[dakuan]

Ich hatte mal ein (fast) ähnliches Problem mit einem Notizzettel Programm. Da hatte ich die Grundeinstellung aus $LANG übernommen. Dabei wurden dann die Verbesserungsvorschläge von Enchant in einem extra Fenster angezeigt. Und da ist dann auch ganz unten noch ein Button für die Sprachauswahl. Da kann dann alles ausgewählt werden, was Enchant an Wörterbüchern gefunden hat. Ich schalte da regelmäßig zwischen de-DE und en-EN um.

Ähnliches mache ich bei Kommentaren in PNG Dateien. Da kann in den iTXt Chunks auch die Sprache ausgewählt werden. Da kann der Benutzer auswählen zwischen "System", "vorgefunden", "manuelle Eingabe" oder "unbekannt". Standardeinstellung ist "unbekannt". Der Punkt ist, dass in den alten tEXt Chunks keine UTF-8 Codierung erlaubt ist (Gimp und exiftool gehen dann von einem Windows Zeichensatz aus).