You are not logged in.
I have reported the following bug concerning Gnome Evolution at Gnome's Gitlab:
composer-attribution-language GUI setting not working & incorrectly implemented
but I'm unable to answer the developer's questions about the glibc locale files on Arch Linux. The developer is using Fedora and they seem to have a completely different setup concerning glibc with glibc langpack packages.
So the problem comes down to the /usr/lib/locale folder, which only contains the file locale-archive on Arch Linux, however on other distributions it also contains directories with respective languages.
More details can be found in the mentioned Gitlab issue.
Can someone here with more insight have a look at that issue at Gitlab, or tell me what information to provide to the Gnome Evolution developer?
Offline
I have been resolving similar problem and found your posts.
For Arch, the path is /usr/share/locale, but Evolution really seems to expect hard path /usr/lib/locale ...
I have achieved partial success by symlinking my locale folders to /usr/lib/locale ...
ls -l /usr/lib/locale
total 5440
lrwxrwxrwx 1 root root 20 Nov 1 15:25 cs_CZ -> /usr/share/locale/cs
lrwxrwxrwx 1 root root 23 Nov 1 15:26 en_GB -> /usr/share/locale/en_GB
lrwxrwxrwx 1 root root 23 Nov 1 15:26 en_US -> /usr/share/locale/en_US
-rw-r--r-- 1 root root 5632896 Nov 1 15:24 locale-archive... then Evolution really enables you to pick desired value.
(Please note in case of cs I had to use full locale name cs_CZ, otherwise it does not work.)
But please be informed that next locale re/generation (eg locale-gen) will delete those symlinks. Also, for me, there is not a full translation of the attribution text, just the name of day is different to match target locale. I don't know if this is an actual bug of Evolution or just an effect of missing something else.
For me it seems I leave this approach and simply use a custom value for composer-message-attribution ... some neutral / universal texting like just the name of sender and date / time.
Last edited by PinoM (2019-11-01 15:03:33)
Offline
@PinoM, thanks for your feedback, I'll try your approach as a temporary solution and inform the developer about your posting.
Offline
@PinoM, I have played around with these symlinks a little, but it is not working as expected, please see the info I have added to the issue on GNOME's Gitlab.
Offline
For me it also does not work as expected in terms of real translating of the attribution text. I have mentioned that. But at least the combo field shows target values, which proves the Evolution expects locales in /usr/lib/locale.
In my opinion the implementation should not work with any hardcoded path, but should use some kind of generic function / command call to get list of generated locales. I don't know if there is a standard global variable defined where system stores glibc locales, probably not. Another way is to expose configuration settings for it (at compile time - packager is responsible ... or at run time - user can set proper path or the Evolution could detect it when ran for first time etc.)
For the check of what Evolution translations are available it seems to be similar scenario. Given that Evolution knows generated locales, it can attempt to detect translations with first run and then on demand from settings etc. I agree that it is not optimal to perform checks with any access to the combo as this could be resource demanding. Some kind of initial analysis and persistence is better way.
I am also waiting and hoping next versions will bring improvements in this.
Offline