Similar topics list on topic creation page pops out only for english themes =/ Will it be for the other languages?
That’s all done through database queries, so it depends what language your database is indexed in, and what language Discourse is set to display.
Thank you for your reply. I want this future working in russian.
I made a clean setup of Discourse by using Docker at DigitalOcean. Discourse language now is ussian. What steps do I need to do?
I looked up the code for this, and it’s using
similarity(topics.title, :title) AS similarity in postgres for that query. Unfortunately, there is no locale parameter, so it seems to depend on the locale of the database if I understand this document correctly.
@Sam is there any way docker could allow a user to set a locale for postgres when bootstrapping so such queries would work in other languages?
Yeah we must let the user set language at bootstrap time.
Barring that @sam for now maybe just mention in the docs or somewhere that it defaults to English and it’s your job (as the forum owner) to change the Postgres database language manually.
We would need to amend the template a bit, but it is doable, we call initdb and can pass in the extra params.
How to do it for a standard Docker installation?
Look at the template you can set the locale, but you would need to start a brand new image and import in.
Do you mean this?
- Make a backup.
- Destroy the old Docker container.
- Create a new one following the official setup guide.
- Configure the locale.
- Import my backup.
Also, can’t we just run an SQL query in postgres?
The locale needs to be set on the initial bootstrap … I will see if I can put a guide up
Thank you very much - this will help a lot, as we’are now filling the forum with the content and I have no knowledge of Docker nor Ruby to play with it all without any guide.
This is still very actual! Any movements in this way so far?
I remembered that it falls back into C locale even if I set the locale as
I tried a fresh install with the correct locale that I need, but still no luck:
- Installed ru_RU.utf8 locale in ubuntu
- Followed official Discourse/Docker install with specifying correct locale in app.yml
- Logged into the docker container and connected to the database
- Checked the locale of the database, and it’s still C
discourse=# show lc_collate; lc_collate ------------ C (1 row) discourse=# show lc_ctype; lc_ctype ---------- C (1 row)
@sam, if I understand correctly, initdb is not using that LOCALE from app.yml, can it be so? :
root@nebaran:/var/docker/templates# grep -r "initdb" * postgres.9.2.template.yml: - "[ ! -e /shared/postgres_data ] && install -d -m 0755 -o postgres -g postgres /shared/postgres_data && s udo -u postgres /usr/lib/postgresql/9.2/bin/initdb -D /shared/postgres_data || exit 0" postgres.template.yml: install -d -m 0755 -o postgres -g postgres /shared/postgres_data_new && sudo -u postgres /usr/lib/postgresql/ 9.3/bin/initdb -D /shared/postgres_data_new || exit 0 postgres.template.yml: - "[ ! -e /shared/postgres_data ] && install -d -m 0755 -o postgres -g postgres /shared/postgres_data && sudo -E -u postgres /usr/lib/postgresql/9.3/bin/initdb -D /shared/postgres_data || exit 0"
I think it picks it up from system locale so if you set it before starting anything it should all, in theory, work magically.
Thanks. I just checked the documentation and it looks as it should:
Locale support is automatically initialized when a database cluster is created using initdb. initdb will initialize the database cluster with the locale setting of its execution environment by default, so if your system is already set to use the locale that you want in your database cluster then there is nothing else you need to do.
However, it did not work. After fresh install I tried to connect to the database and got this:
locale -a inside the container says there aren’t any
ru languages, so it seems as in either way the right solution is to amend the launcher… it’s a pity as I have no enough knowledge to do it in a few hours.
I can rebuild database (i.e. backup/destroy/create) or try and make my local customization to the launcher, but I’m afraid to get into trouble later if anything core will be updated and I’ll have to deal with merging. I prefer not to touch core things for production setups - is this right?
pg documentation says we can setup it separately per database when we create it, so should it be the preferred way then? Because in a multisite setup there might be different locales for different databases if one decides to run multiple language versions of their forum.
initdb initializes the database cluster’s default locale and character set encoding. The character set encoding, collation order (LC_COLLATE) and character set classes (LC_CTYPE, e.g. upper, lower, digit) can be set separately for a database when it is created. initdb determines those settings for the template1 database, which will serve as the default for all other databases.
Specifies the locale to be used in this database. This is equivalent to specifying both --lc-collate and --lc-ctype.
@sam, could you please have a look if you can introduce that change in the launcher?
It looks as if no locale is registered in the container by default, so the idea of just setting the environment locale as a temporary solution fails - the database is created by the time I’d install locales needed in the container environment. What is more, if I do it manually, I’ll lose it on the next rebuild.
Setting LANG: ru_RU.UTF-8 in app.yml does not work when bootstrapping docker container
How to change pg locale for better search after Discourse has been installed with Docker?
I might be going off in a bit of a tangent – but this is about the similar topic feature not working due to full text search, right? If so, the locale might not matter in the first place as there should be no appreciable differences in character classification (CTYPE) between
ru_RU.UTF-8 (as classification is defined by Unicode in these locales) and character ordering (COLLATE) should not have any negative impact on full text search.
Instead, have you tried changing the
default_text_search_config setting in the container’s
postgresql.conf file to
more info about this issue here, fwiw:
So, I might be dumb a bit, but @elberet, can you tell us an acceptable solution for now?
Not really, I’m in no way a PostgreSQL expert and I don’t know for certain if these things would actually solve your specific problems.