I've got a problem with the language localization in TYPO3.
The site works fine, I don't get any warnings or erros in the 'normal' TYPO3-log in the backend. But every minute I got a new line in sitename/var/logs/typo3_abc.log saying
Thu, 23 Jul 2020 13:14:55 +0000 [ERROR] request="4fc10d4752ec5" component="TYPO3.CMS.Core.Localization.Locales": Locale "en_US.UTF-8" not found.
This is my config.yaml
languages:
-
title: English
enabled: true
base: /
typo3Language: default
locale: en_US.UTF-8
iso-639-1: en
websiteTitle: ''
navigationTitle: English
hreflang: en-US
direction: ''
flag: en-us-gb
languageId: '0'
Any hints or suggestions what is missing?
My system:
TYPO3 Version 10.4.5 as a container with php:7.2-apache.stretch and MariaDB Version 10.2 .
clean declaration, but does it match to your available locals?
check the list of available locales with locale -a in a shell on your system.
maybe it is written a little bit different like en_US.utf8 or en_US.utf-8 or en_US.UTF8 or ...
Related
I want to use an ICU system-insensitive sorting collation, to avoid sorting differences between postgres11-on-mac vs postgres11-on-Ubuntu. My first test was to dump out my existing Collate=en_US.UTF-8 and pg_restore them into a db created with Collate=en-US-x-icu
Create Database doc has this to say:
To create a database music with a different locale:
CREATE DATABASE music
LC_COLLATE 'sv_SE.utf8' LC_CTYPE 'sv_SE.utf8'
TEMPLATE template0;
I seem to have the required icu locales already:
select collname, collprovider from pg_collation where collname like 'en_US%';
collname | collprovider
------------------------+--------------
en_US.UTF-8 | c
en_US | c
en_US.ISO8859-15 | c
en_US.ISO8859-1 | c
en_US | c
en_US | c
en-US-x-icu | i 👈
en-US-u-va-posix-x-icu | i 👈
(8 rows)
But no luck when creating a database with either icu locales.
CREATE DATABASE test LC_COLLATE = 'en-US-x-icu' TEMPLATE template0;
ksysdb=# CREATE DATABASE test LC_COLLATE = 'en-US-x-icu' TEMPLATE template0;
ERROR: invalid locale name: "en-US-x-icu"
I can use LC_COLLATE with other locales:
The LC_COLLATE clause does seem to come with some strings attached, such as watching your encoding and specifying an appropriate template. But it seems to give error hints w non-ICU locales.
This works, for example: CREATE DATABASE test LC_COLLATE = 'en_US' TEMPLATE template0;
and this one gives a helpful user message:
ksysdb=# CREATE DATABASE test LC_COLLATE = 'en_US.ISO8859-15' TEMPLATE template0;
ERROR: encoding "UTF8" does not match locale "en_US.ISO8859-15"
DETAIL: The chosen LC_COLLATE setting requires encoding "LATIN9".
Note: a related question, PostgreSQL 10 on Linux - LC_COLLATE locale en_US.utf-8 not valid, doesn't seem all that relevant, as the answer talks about generating an OS-level locale to fix the issue. While the ICU locales, as far as I understand, are expressly intended to be separated from the underlying OS.
I have read all documentation and something that seems obvious is not happening in my installation. I have several domains:
domain.net
domain.fr
domain.it
all of them are pointing the typo3 folder in server. After adding all these domains and corresponding languages in site management > sites
I still only get original frontend in .net domain rest wont show anything (blank).
Note: most information online is older versions and it seems that this point has been simplified in this version, so there is no need to include any code in .htaccess or other files. Also followed this
Looking into my folder tree I can see these folders (for each site) in mainfolder/typo3conf/sites and every of them has its config.yaml file.
Substituted real name for "domain"
this is what .net looks like (english version)
base: 'https://example.net/'
baseVariants: { }
errorHandling: { }
languages:
-
title: English
enabled: true
base: 'https://example.net/'
typo3Language: default
locale: en_US.UTF-8
iso-639-1: en
websiteTitle: ''
navigationTitle: English
hreflang: en-US
direction: ltr
flag: en-us-gb
languageId: '0'
rootPageId: 1
routes: { }
websiteTitle: ''
This is .fr (french version)
base: 'http://example.fr/'
baseVariants: { }
errorHandling: { }
languages:
-
title: French
enabled: true
languageId: '0'
base: 'http://example.fr/'
typo3Language: fr
locale: fr_FR.UTF-8
iso-639-1: fr
navigationTitle: Français
hreflang: fr-fr
direction: ltr
flag: fr
websiteTitle: ''
rootPageId: 2
routes: { }
websiteTitle: ''
Tree inside is just this
Pages have dummy content we arent developing anymore until this problem is solved.
Any idea?
Server setup should be ok as before typo3 i was able to have a wordpress multisite and it did show content. As WP isnt native multilanguage and it works with all kind of plugins that just break everything when you update. This is why we are changing to typo3. But that is another story.
Usually when everything seems fine but it doesnt work, its something silly.
.fr domains and others were handling a lower version of php so it wouldnt run typo3
So if something like this happens to you check php version on every domain!!!
I try to use wget to fetch the all the sites of my typo3 project. The target is to make a cronjob with this command to build the cache and the search index. While testing the command wget shows a weird behaviour.
The OS is Opensuse Tumbleweed running Apache and MySQL.
Typo3 9.5.9 was installed via composer. The composer.json is in /srv/www/typo3install, Documentroot ist /srv/www/htdocs.
The environment module of typo3 says all my permissions are ok (htaccess difference for static file cache).
This is my site configuration (config.yaml):
rootPageId: 1
base: /
baseVariants: { }
languages:
-
title: Deutsch
enabled: true
languageId: '0'
base: /
typo3Language: de
locale: de_DE.UTF-8
iso-639-1: de
navigationTitle: Deutsch
hreflang: de
direction: ''
flag: de
-
title: English
enabled: true
languageId: '1'
base: /en/
typo3Language: default
locale: en_UK.UTF-8
iso-639-1: en
navigationTitle: English
hreflang: en
direction: ''
fallbackType: fallback
fallbacks: '0'
flag: gb
errorHandling: { }
routeEnhancers:
PageTypeSuffix:
type: PageType
map:
sitemap.xml: 1533906435
routes:
-
route: robots.txt
type: staticText
content: "User-agent: *\r\n\r\n# Only allow URLs generated with RealURL\r\nDisallow: /*?id=*\r\nDisallow: /*&id=*\r\n\r\n# L=0 is the default language\r\nDisallow: /*?L=0*\r\nDisallow: /*&L=0*\r\n\r\n# typeNum = 98 is usually the print version.\r\nDisallow: /*?type=98*\r\nDisallow: /*&type=98*\r\n\r\n# Should always be protected (.htaccess)\r\nDisallow: /*/Private/*\r\nDisallow: /fileadmin/templates/html/*\r\nDisallow: /*/Configuration/*\r\n\r\nDisallow: /typo3temp/*\r\nAllow: /typo3temp/*.css\r\nAllow: /typo3temp/*.css.*.gzip\r\nAllow: /typo3temp/*.js\r\nAllow: /typo3temp/*.js.*.gzip\r\nAllow: /typo3temp/*.jpg\r\nAllow: /typo3temp/*.gif\r\nAllow: /typo3temp/*.png\r\n\r\nDisallow: *.sql\r\nDisallow: *.sql.gz\r\n\r\nDisallow: /typo3/\r\nDisallow: /typo3_src/\r\nDisallow: /template/\r\nAllow: /typo3/sysext/frontend/Resources/Public/*\r\nAllow: /template/Resources/Public/*\r\nSitemap: localhost/sitemap.xml\r\nSitemap: localhost/sitemap.xml"
disableStaticFileCache: false
The httpd.conf for the documentroot:
<Directory "/srv/www/htdocs">
Options Indexes FollowSymLinks ExecCGI Includes
AllowOverride All
Require local
</Directory>
The command:
wget -v -r http://localhost -P /srv/www/htdocs/typo3temp/tmpbuild
This fetches only the content of /srv/www/htdocs/typo3temp. But if I start with a subpage of the page tree the whole site gets fetched:
wget -v -r http://localhost/products/ -P /srv/www/htdocs/typo3temp/tmpbuild
I think this is not the behaviour as it should be: starting with the base URL should fetch the whole tree.
I can´t figure out if i have missed an option of wget or if there is something wrong with my configuration.
Thanks in advance,
Starger.
P.S.: Creating a hidden subpage and use this as a starting point works. But this is just a workaround.
I had to do some changes (switch to HTTP2 and SSL) on the server and the problem seems to be not present anymore.
After an upgrade from Ubuntu Server 14.04 to 16.04 I had to also upgrade my Postgres clusters from 9.3 to 9.5. The normal way to do that is to first drop the (empty) 9.5 cluster that the upgrade created:
# pg_dropcluster 9.5 main
and then to upgrade the old 9.3 cluster to 9.5:
# pg_upgradecluster 9.3 main
This however results in an error:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US.UTF-8",
LC_ALL = (unset),
LC_PAPER = "nl_NL.UTF-8",
LC_ADDRESS = "nl_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_NUMERIC = "nl_NL.UTF-8",
LC_TELEPHONE = "nl_NL.UTF-8",
LC_IDENTIFICATION = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LC_TIME = "nl_NL.UTF-8",
LC_NAME = "nl_NL.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").
Error: The locale requested by the environment is invalid.
Error: Could not create target cluster
This means I could not upgrade to Postgres 9.5.
I checked all locale settings:
the en_US.UTF-8 locale exists and is properly generated as checked with locale -a (it shows en_US.utf8 in its list)
The file /etc/environment contains LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8
/etc/default/locale contains the same setting for LANG, LANGUAGE and LC_ALL
I can start Perl without any issue using "perl -e exit"
The error message is generated from the pg_createcluster script which is called from pg_updatecluster. But running pg_createcluster from the command line works just fine, without any issue.
Workaround for the issue:
I used the following workaround to at least get the conversion to work. I edited the /usr/bin/pg_upgradecluster script, as follows:
Find the code where it calls pg_createcluster by looking for the comment "create new cluster"
That code consists of a series of "push" statements, ending in the suspicious line:
delete $ENV{'LC_ALL'}
Notice that this LC_ALL is exactly the variable that is unset in the error message.
Comment out that delete comment by adding a '#' before it, then save.
This at least circumvents this problem and lets you run the upgrade.
My question: is this a bug in the pg_upgradecluster script, or is something else awry on my system?
had the same problem on an ubuntu 16.04 server. what helped in my case was to generate all the locales that appear in your listing of $ locale:
$ sudo locale-gen "en_US.UTF-8"
$ sudo locale-gen "nl_NL.UTF-8"
good luck!
In my case, it was complaining about
Error: The locale requested by the environment is invalid:
LANG: en_GB
LANGUAGE: en_GB:en
So I unset LANG and unset LANGUAGE and it worked.
For me, I have followed many suggestions and still didn't work.
The script mentioned
LC_TIME=en_UK but it's totally unrelated so I ignored it at first.
Turns out this was the problem and doing "unset LC_TIME" was all I needed.
Posting here in case it happened to someone else.
My quick way to disable that message: (macOS 12 Monterey M1)
Open Terminal -> Preferences -> Advanced tab -> uncheck to Set locale environment variables on startup
Just came across this in fresh Ubuntu + PostgresQL install, after all those years.. either way, the solution is:
apt-get install locales
Could anybody give an insight on the locale and numeric types behaviour in PostgreSQL? We work with Italian locale. That is comma separation for decimal part. Setting in postgresql.conf
# These settings are initialized by initdb, but they can be changed.
lc_messages = 'it_IT.UTF-8' # locale for system error message
# strings
lc_monetary = 'it_IT.UTF-8' # locale for monetary formatting
lc_numeric = 'it_IT.UTF-8' # locale for number formatting
lc_time = 'it_IT.UTF-8' # locale for time formatting
.. does nothing! It behaves in a quite appropriate way with dates and so, BUT the numeric type remains DOT separated for decimal part.
root#server:~# uname -a
Linux server 2.6.32-36-generic-pae #79-Ubuntu SMP Tue Nov 8 23:25:26 UTC 2011 i686 GNU/Linux
root#server:~# dpkg -l | grep postgresql
ii postgresql-8.4 8.4.9-0ubuntu0.10.04 object-relational SQL database, version 8.4
ii postgresql-client 8.4.9-0ubuntu0.10.04 front-end programs for PostgreSQL (supported)
EDIT
Having problem with implementation of locale in different scopes: db, server script, os and client side. Decided to avoid any locale formatting and use en_EN locale. The locale formatting will be applied only at the moment of output and so.
I quote the manual:
lc_numeric (string)
Sets the locale to use for formatting numbers, for example with the to_char family of functions.
Concerns these type formatting functions. You should be able to reproduce the following demo:
SHOW lc_numeric;
de_AT.UTF-8
SELECT to_number('13,4','999D99')
13.4
SELECT to_char(13.4,'FM999D99')
13,4
SET lc_numeric = 'C';
SELECT to_number('13,4','999D99')
134
SELECT to_char(13.4,'FM999D99')
13.4
RESET lc_numeric;
Template patterns in the manual.
The format of numbers in SQL expressions does not change with locale settings. That would be madness.
On a different note: you are aware that you have to (at least) reload the server after changing postgresql.conf.
pg_ctl reload