Ik draai Tumbleweed en ben daar best tevreden over, een probleem met locale krijg ik echter niet makkelijk opgelost.
Ik wil graag de overal Engels gebruiken maar niet voor de settings wat betreft getalformaten, data, geldeenheden etc. dus daarom heb ik m.b.v. Yast in de Language settings de Primary Language op English (US) gezet en Dutch als Secondary Language geselecteerd.
Verder heb ik in de “System Settings” applicatie onder Personalization “Regional Settings” de Preferred Languages op “American English” staan maar onder Formats heb staat de Region op “Nederlands - English (en_NL)” en dat is denk ik precies hoe ik het wil.
Het probleem is nu dat en_NL niet helemaal ondersteud wordt.
Als ik bijvoorbeeld een perl script draai:
> ./script.pl
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = (unset),
LANG = "en_NL.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Ik heb al het é[size=][FONT=Verdana]é[/FONT][/size]n en ander geprobeerd maar snap nog niet waar het probleem zit.
> locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_NL.UTF-8
LC_CTYPE="en_NL.UTF-8"
LC_NUMERIC="en_NL.UTF-8"
LC_TIME="en_NL.UTF-8"
LC_COLLATE="en_NL.UTF-8"
LC_MONETARY="en_NL.UTF-8"
LC_MESSAGES="en_NL.UTF-8"
LC_PAPER="en_NL.UTF-8"
LC_NAME="en_NL.UTF-8"
LC_ADDRESS="en_NL.UTF-8"
LC_TELEPHONE="en_NL.UTF-8"
LC_MEASUREMENT="en_NL.UTF-8"
LC_IDENTIFICATION="en_NL.UTF-8"
LC_ALL=
> locale -a | grep NL
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
fy_NL
li_NL
nds_NL
nl_NL
nl_NL.utf8
nl_NL@euro
> localectl list-locales | grep NL
en_NL
en_NL.utf8
fy_NL
li_NL
nds_NL
nl_NL
nl_NL.utf8
nl_NL@euro
> localedef --help
...
System's directory for character maps : /usr/share/i18n/charmaps
repertoire maps: /usr/share/i18n/repertoiremaps
locale path : /usr/lib/locale:/usr/share/i18n
> ls /usr/lib/locale/ | grep NL
en_NL
en_NL.utf8
fy_NL
li_NL
nds_NL
nl_NL
nl_NL.utf8
nl_NL@euro
locale kent dus niet “en_NL.UTF-8” maar localectl en localedef kent wel “en_NL.utf8”, is het problem in het verschil tussen UTF-8 en utf8? Lijkt me niet.
Het is wel vreemd dat je in Yast de taal kan configureren maar niet de Formats en in “System Settings” nogmaals de taal kan zetten en de Formats.
Ik vind je verhaal redelijk ingewikkel, maar dat ligt denk ik aan mij (ik zal het allemaal nog een sdoorlezen).
Ik zou er zelf niet aan hebben gedacht dat en_NL zou kunnen bestaan. Ik dacht altijd dat het ene de taal was en het andere een variant daarop. Zoals en_AU voor de australische versie van engels en en_UK voor de GB versie, enz. Bij zo.n idee past en_NL natuurlijk niet (nog niet, er zijn mensen die geheel op engels willen overgaan en dan krijg je natuurlijk onze eigen versie).
Ik heb overigens het idee dat je het onderscheid tussen systeem instellingen en persoonlijke instellingen van een gebruiker (meestal in een desktop als KDE) door elkaar haalt. YaST is voor systeeminstellingen en daar komen Formats niet bij te pas. Alleen de taal wordt gebruikt om meldingen in verschillende talen te ondersteunen.
Ik heb nog wat verder gezocht en het is inderdaad zo dat de code vóór de _ de taal aangeeft en de code na de _ een streek of regio waar een versie van die taal gesproken wordt (ze praten in het engels over een “dialect”, maar ik denk dat taalkundigen dat een onjuist gebruik van het woord vinden).
Aangezien er in NL geen versie van en wordt gesproken (het beruchte “steenkolenengels” niet meegerekend), is het geen wonder dat en_NL niet wordt ondersteund. Het bestaat gewoon niet.
Goed te weten wat het verschil is tussen de systeem instellingen en persoonlijke instellingen van een gebruiker daar is denk ik ook waar het fout gaat.
In Yast kan je bij de Taal instellingen rechts van de selectie van de Primaire taal een knop Details vinden en daaronder komt een selectiebox met de Gedetailleerde Locale Settings. Als ik die aan klik krijg ik een lijst die allemaal met en_ beginnen en onder andere en_US, en_AU, en_NZ, en_GB, en_IE maar ook en_BE en hoewel ik twijfel of BE voor België of Wit-Russisch (Belrus) staat, hebben beide landen niet Engels al voertaal, dus waarom en_NL niet?
Volgende vraag is dus hoe die lijst in Yast komt en hoe daar een “locale setting” aan toe te voegen. Ik denk dat Yast dezelfde lijst gebruikt als “locale -a” en (zie de log) die laat inderdaad en_NL niet zien. Wat me verbaasd is dat localectl en localedef wel en_NL lijken te kennen, ik had gedacht dat al die programma’s dezelfde data bron gebruiken.
Bedankt voor je reactie Henk, toch een beetje verder.
Tja, een hoop informatie erbij. En ik kan dat definitie bestand zo gauw ook niet interpreteren. Ik denk ook dat de inhoud nogal arbitrair is. Niet iedereen zal bij een_NL denken aan dezelfde waarden. Ik kan mij bijv. indenken dat jij andere redenen hebt om een en_NL te willen dan iemand anders (in de artikelinleiding wordt over expats gepraat, dat ben jij geloof ik niet). In het bestand wordt bijv. veel uit en_US overgenomen. Een andere expat wil misschien willen uitgaan van en_UK.
De theorie bij dit soort zaken is altijd fantastisch. Maar bij dingen, die via omgevingsvariabelen worden doorgegeven, is het altijd maar de vraag welke applicaties die variabelen ook interpreteren.
Op systeem niveau vindt ikhet niet zo belangrijk. Ik gebruik bij installatie altijd de verstekwaarde (en_US denk ik) omdat ik de vaktermen dan beter begrijp. Tenslotte gebruik je bij systeembeheer geen bedragen in € en zo.
Mijn persoonlijke desktop zet ik dan weer op waarden zoals ik ze wil: nederlands, een , voor cijfers “achter de komma”, enz. In KDE kon ik dat individueel zetten. Maar in de nieuwste KDE hebben ze dat verpest. Als je bijv de datum in cijfers op de ISO standaard yyyy-mm-dd wilt zetten kan dat niet. Je krijgt een eindeloze rij vlaggetjes van landen (nogal kinderlijk) en daaruit moet je kiezen. Als je Nederland kiest is die datum in cijfers dus niet zoals ik wil. Eén of andere idioot heeft bedacht dat dat in Nederland anders is. Het is misschien zoals velen dt doen, maar het is niet volgens the NEN norm (die de ISO volgt) en ook niet wat ik wil. Het is één van de dingen die mij er tot nu toe van weerhoudt om op 42.2 over te stappen.
En daar wordt o.a. ook gepraat over nederlandse expat in Engeland. Dat is natuurlijk weer een heel ander combinatie nl_UK. Daar zijn ze voorlopig nog niet uitgekibbeld.
Zoals ik hierboven al aangaf: verschillende doelgroepen en afwachten wie het luidste roept.>:)
Mijn persoonlijke desktop zet ik dan weer op waarden zoals ik ze wil: nederlands, een , voor cijfers “achter de komma”, enz. In KDE kon ik dat individueel zetten. Maar in de nieuwste KDE hebben ze dat verpest.
Ik zat nog tot een maand geleden op 13.2 omdat ik dat migreren maar moeizaam vind, dus daarom maar gelijk naar Tumbleweed, dan hoef je niet om, maar ga je automatisch om…
Zo ziet het er in Tumbleweed KDE uit, lijkt erop alsof je de formaten weer individueel kan zetten, dus om naar Tumbleweed?
Nee, via Detailed Settings het korte datumformaat omzetten naar 2017-04-24 lukt niet, ik zie nu de liijst met vlaggen die je eerder noemde.
Lijkt me een gevalletje van een eigen territorium definiëren (er zijn er pas drie beginnend met een ‘H’, dus keus zat) en daar een definitiefile voor maken met de juiste instellingen en dan die aan het systeem bekend maken.
Dat laatste, het aan het systeem bekend maken, is wat ik ook aan het proberen ben.
Ja, de gebruiker niet de keuze voor settings gebaseerd op een land maar “gewoon” via een formatstring heeft ook z’n charme
Ik zie wel een beetje waar de schoen wrijft, locale werkt met regions en niet met individuele settings, maar aan de andere kant zijn de codes AA, QM tot QZ, XA tot XZ en ZZ gereserveerd voor “in-house applications” dus zo zou het mogelijk moeten blijven een user-locale te maken die gebaseerd is op individuele keuzes en die te gebruiken.
Alleen maar een idee: Sommige dingen in KDE zijn pas waar na uit- en weer inloggen. In sommige delen van KDE wordt dat keurig gemeld ( klooi maar wat met anti-aliasing, keurig ), maar niet overal. In de US gebruiken ze wel NEN ISO datum notatie.
Terzijde: ik ken nogal wat ontwikkelomgevingen, en datum formaten is zo makkelijk nog niet. Zodanig bijv. dat php al jaren meldt dat het date commando vervangen moet worden door date_time_zone, maar als je dat doet in een bestaande omgeving heb je een probleem met je bestaande data die keurig zijn omgerekend naar een UNIX tiimestamp. Horgh.
Kort samengevat de argumenten in de desbetreffende discussies bij KDE:
Het heeft altijd gekund, waarom zijn oude gebruikers de pineut met deze regressie??
Het is gewoon de ISO standaard, als je die niet kunt gebruiken waar blijvem we dan?
En mijn toevoeging, hoewel onze NEN norm “Het schrijven van de datum in cijfers” eigenlijk een vertaling van de ISO norm is en dus ook 2017-04-26 geeft, geeft het NL vlaggetje iets anders. Kortom welke … denkt hier bepaald te hebben dat NL iets niet standaard moet tonen.
