Warum gibt es kein "Euro English" Gebietsschema?

Früher habe ich bei der en_DK.UTF-8Installation eines neuen Systems das etwas skurrile Gebietsschema verwendet, da dies (in etwa) die gewünschten Ergebnisse für das Gebietsschema liefert, obwohl ich nicht in Dänemark bin.

• Maße metrisch
• Sinnvolle Datums- und Uhrzeitformate, aber Tages- und Monatsnamen in englischer Sprache
  • 24-Stunden-Zeitformat
  • Die Arbeitswoche beginnt am Montag
  • Numerisches Datum im (zumindest ähnlichen) ISO-Format, JJJJ-MM-TT
  • Informelles Datum ist TT / MM, nicht umgekehrt
• A4-Papiergröße
• Euro Währung
• Systemmeldungen in Englisch

Leider scheinen Ubuntu und Debian das en_DKGebietsschema nicht mehr zu unterstützen . Ich habe gedacht, es sollte so etwas wie en_EU"Euro English" geben.

Jeder Ort, an dem ich gearbeitet habe, hatte solche Anforderungen - die offizielle Sprache der Organisation ist Englisch, aber wir wollen für alles andere kontinentaleuropäische Vorgaben.

Ich stelle mir vor, dass ich nicht der erste bin, der denkt, dass ein "standortunabhängiges" englisches Gebietsschema sowohl mir persönlich als auch den Organisationen, für die ich arbeite, zugute kommt. Warum existiert es also nicht und wo suche ich nach weiteren Diskussionen und Begründungen?

... Oder soll ich es vorschlagen? An wen?

(a) Eine als Unicode Common Locale Data Repository bekannte Entität scheint der Ort zu sein, an dem die Gebietsschemata verwaltet werden. Das glibc-Wiki zeigt an, dass sie CLDR folgen werden .

(b) Sie haben ein Gebietsschema mit der Bezeichnung "en_150", das anscheinend dazu bestimmt ist, das zu tun, was Sie wollen. Ich bin mir nicht sicher, ob glibc es bereits implementiert hat. Es gibt auch ein ähnliches Gebietsschema namens en_BE, das mit en_150 identisch ist, mit der Ausnahme, dass es eine regionale Abdeckung von BE hat und nicht weltweit.

en_IE.UTF-8 Das Gebietsschema Englisch (Irland) bietet alles, was Sie sich wünschen:

• Maße metrisch - ja
• 24-Stunden-Zeitformat - ja
• Die Arbeitswoche beginnt am Montag - ja
• Numerisches Datum im (zumindest ähnlichen) ISO-Format, JJJJ-MM-TT - nein , es ist dieses Gebietsschema dd/mm/yy. Aber das scheint nah genug an dem zu sein, was du gewohnt bist
• Informelles Datum ist TT / MM, nicht umgekehrt - ja
• A4-Papiergröße - ja
• Eurowährung - ja
• Systemmeldungen in Englisch - ja

Eigentlich verwende ich dieses Gebietsschema, obwohl ich in Amsterdam bin, da es kein englisches (paneuropäisches) Gebietsschema gibt, das ich kenne.

BTW. Machen Sie keinen Fehler bei der Auswahl des ga_IE.UTF-8irischen (irischen) Gebietsschemas, da es sich um eine irisch-gälische Sprache handelt.

Das Gebietsschema en_DK hat mit Ausnahme des Namens nichts mit Dänemark zu tun. Es wurde ursprünglich von jemandem erstellt, der dasselbe wie hier angefordert haben wollte - ein angemessener Satz von Standardwerten für einen Englisch sprechenden Europäer. Der Name "en_DK" ist eine Art Scherz - alle Ortsnamen zu dieser Zeit bestanden aus einem Sprachcode und einem Ländercode (es gab keine Kontinentcodes oder etwas anderes an zweiter Stelle), und aus welchem ​​Grund auch immer Dänemark gewählt wurde der Platzhalter-Ländercode. (... und hat seitdem wahrscheinlich mehr als eine mystifizierte Person veranlasst, den Anteil der Menschen in Dänemark zu untersuchen, deren Muttersprache Englisch ist. :))

Aus diesem Grund verwenden Sie unterschiedliche Ländereinstellungen für unterschiedliche Aufgaben.

In meinem Fall mische ich en_GB und sv_SE, um das zu erhalten, was ich brauche und es sieht so aus:

$> locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC=sv_SE.utf8
LC_TIME=sv_SE.utf8
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY=sv_SE.utf8
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER=sv_SE.utf8
LC_NAME=sv_SE.UTF-8
LC_ADDRESS=sv_SE.UTF-8
LC_TELEPHONE=sv_SE.UTF-8
LC_MEASUREMENT=sv_SE.utf8
LC_IDENTIFICATION=sv_SE.UTF-8
LC_ALL=

Aber Sie würden wahrscheinlich sv_SE durch dk_DK ersetzen.

Und um € zu bekommen, benutze LC_MONETARY = en_IE.UTF-8

Ich speichere dann meine Konfiguration als viele Exporte in ~ / .profile

export LC_MONETARY="en_IE.UTF-8"

Dies gibt Ihnen die Möglichkeit, die "richtigen" Dinge aus verschiedenen Bereichen auszuwählen.

Eigentlich glaube ich, dass es ein Gebietsschema gibt, das Ihren Anforderungen besser entspricht als en_IE. Es ist inoffiziell, aber es ist en_SE.UTF-8. Dies ist ein Link, der auf die Gebietsschemadatei verweist.

Es kopiert im Grunde sv-SE, was Ihnen alles bringen sollte, was Sie wollen (obwohl ich es nicht doppelt überprüft habe), aber es gibt Ihnen englische Systemmeldungen, Menüs usw. Ich habe es schon einmal benutzt und es hat sehr gut für mich in gearbeitet Üben Sie trotz der Einschränkungen im Kommentarblock oben in der Datei.

Installieren:

1. Download, so dass die Locale-Datei als zugänglich ist /usr/share/i18n/locales/en_SE
2. Lauf sudo localedef -i en_SE -f UTF-8 en_SE.UTF-8
3. füge /var/lib/locales/supported.d/localder Zeile hinzu en_SE.UTF-8 UTF-8(könnte je nach Distribution unterschiedlich sein; Debian Squeeze / 6.0 scheint damit zufrieden zu sein /etc/locale.gen)
4. Lauf sudo locale-gen
5. Setzen Sie Ihr System- oder Account-Standardgebietsschema auf en_SE.UTF-8(zum Beispiel bis /etc/default/localeauf Debian-ähnliche Systeme)
6. Starten Sie den Computer neu oder melden Sie sich ab und wieder an, um das neue Gebietsschema zu aktivieren

ich benutze en_IE@euro ISO-8859-15

$ export LC_MONETARY= "en_IE@euro ISO-8859-15" 

... aber ich bin mir nicht ganz sicher, ob ich Messungen in Betracht ziehe nl_NL.UTF-8oder nl_BE.UTF-8. Das einzige Problem, das ich dabei habe, ist, wenn ich eine solche Bibliothek zulasse, dass andere Apps sie möglicherweise als Referenz für die lokale Bibliothek verwenden und erneut Apps herunterladen und Service in Niederländisch oder sogar Deutsch.

winetricks haben mich letzte Nacht an die Wand getrieben, und vcrun6selbst nachdem ich locale-geneinen Hinweis auf die deutsche Bibliothek entfernt hatte, wurde immer noch eine deutsche Version von heruntergeladen redistributablec++, schließlich wurde dies manuell durchgeführt, indem die exe komplett mit Wein gestartet wurde.

Unglaublicherweise bin ich wieder hier, um das gleiche Problem zu lösen. Dieses Mal ist es APT und das lokale belgische Repo wollte unbedingt meine Locale-Konfiguration bearbeiten. Dies ist nicht möglich, da ich die Berechtigungen bearbeitet habe. Stattdessen erhalte ich nur Fehlermeldungen:

Fetched 207 kB in 0s (1381 kB/s)
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
    LANGUAGE = "en",
    LC_ALL = (unset),
    LC_TIME = "nl_BE.UTF-8",
    LC_MONETARY = "en_IE@euro ISO-8859-15",
    LC_ADDRESS = "nl_BE.UTF-8",
    LC_TELEPHONE = "nl_BE.UTF-8",
    LC_MESSAGES = "en_IE.UTF-8",
    LC_NAME = "en_IE.UTF-8",
    LC_MEASUREMENT = "nl_BE.UTF-8",
    LC_IDENTIFICATION = "en_GB.UTF-8",
    LC_NUMERIC = "nl_BE.UTF-8",
    LC_PAPER = "en_IE.UTF-8",
    LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory 

Kein Kompromiss, alles oder nichts. Die einzige andere Lösung wäre, das Repo zu ändern, aber ich werde nie völlig störungsfrei sein, da die Tastatur von AZERTY ist und laut Gesetz nur Französisch von Belgisch Niederländisch funktioniert. (

Unter https://github.com/PanderMusubi/locale-en-nl finden Sie ein korrektes englisches Gebietsschema für die Niederlande, das nicht festgelegt werden kann, indem vorhandene Gebietsschemas anhand ihrer LC_-Umgebungseinstellungen neu gemischt werden.