Skip to first unread message
guilher...@gmail.com
Aug 20, 2019, 9:25:49 AM8/20/19
to AtoM Users
Hello.
I'm having problems setting the default language of the website, when accessing it as anonymous user (not logged in or a browser anonymous tab). It just won't change from the default (US) to what i want (pt_BR).
I've tried so far, no success:
- Changed the default_culture parameter at settings.yml to pt_BR
- restarting php, memcached and even the server
- reindexing with search:populate
- clearing cache with cc
My server is Ubuntu 16.04 and the atom version is (2.5.1 - 172).
I was wondering if is possible to completly remove the english languange option or maybe set the default language value directly to the database.
Thank you
Corinne Rogers
Aug 20, 2019, 11:18:16 AM8/20/19
to AtoM Users
Hi Guilherme,
If I understand your question, you want anonymous users to see the website in pt_BR instead of US, but when you (as an admin user) try to make that change, it is not saved?
From the thread on this topic here:
AtoM is designed to be a multilingual application, so users can add content in different languages. Most fields in the database, including the static pages, are split into i18n tables (which is developer-speak for internationalization), so you can add different content for each culture in use.
However, if you are using AtoM in a monolingual site, there are a couple of things you can do to improve the end user experience.
First, navigate to Admin > Settings > i18n languages, and remove every language expect the default installation culture of your site. You should reindex your site after doing so. See:
Additionally, you can hide the entire language menu from view, via Admin > Settings > Default page elements. See:
Doing so should prevent users and bots from stumbling across the other page versions.
I hope that helps!
best regards,
Corinne
brigitte...@gmail.com
Sep 30, 2019, 1:39:21 PM9/30/19
to AtoM Users
Hello,
I am new to AtoM. I have just installed version 2.5.2 on Ubuntu 18.04.3.
It seems to be working fine except for the same problem as Guilherme. I cannot change the default language to "fr". I have changed the settings.yml file, cleared the cache, rebooted, it always return to english.
Also, I cannot remove "english" from the settings.
Any idea for a newbie?
Thank you
Brigitte
Le mardi 20 août 2019 11:18:16 UTC-4, Corinne Rogers a écrit :
Hi Guilherme,If I understand your question, you want anonymous users to see the website in pt_BR instead of US, but when you (as an admin user) try to make that change, it is not saved?
From the thread on this topic here:AtoM is designed to be a multilingual application, so users can add content in different languages. Most fields in the database, including the static pages, are split into i18n tables (which is developer-speak for internationalization), so you can add different content for each culture in use.However, if you are using AtoM in a monolingual site, there are a couple of things you can do to improve the end user experience.First, navigate to Admin > Settings > i18n languages, and remove every language expect the default installation culture of your site. You should reindex your site after doing so. See:Additionally, you can hide the entire language menu from view, via Admin > Settings > Default page elements. See:Doing so should prevent users and bots from stumbling across the other page versions.I hope that helps!best regards,Corinne
Brigitte Moore
Sep 30, 2019, 2:14:15 PM9/30/19
to AtoM Users
me again!
I have solved my problem. I changed the language of my Linux installation to french and my AtoM site opened in french. :-)
thanks
Brigitte
Dan Gillean
Oct 1, 2019, 11:59:04 AM10/1/19
to ICA-AtoM Users
Hi Brigitte,
Thanks for updating us on your progress!
I have tried to recreate the issue you experienced, but locally I was able to change my default culture without any issues. I'm glad to hear you've got things working as you need to - but just in case it helps others, I will share some general thoughts below.
First, to make sure that any settings changes stick it can be a good idea to make sure that the permissions are properly set in your installation. Everything should be owned by the www-data user - you can try resetting the permissions by running the following command from AtoM's root installation directory (which is typically /usr/share/nginx/atom if you have followed our recommended installation instructions):
- sudo chown -R www-data:www-data /usr/share/nginx/atom
See for example: https://www.accesstomemory.org/docs/latest/admin-manual/installation/linux/ubuntu-bionic/#filesystem-permissions
The configuration file where the default culture is set is found within AtoM at: apps/qubit/config/settings.yml
A couple things about editing this file:
First, if you change the language code, make sure you maintain the existing spacing between the default_culture label and the value. Make sure you are using a valid ISO 639-1 language code - a list of supported languages in AtoM and their codes can be found here:
Make sure you save your changes properly in the config file - how you do this will depend on what text editor you use in your console. I personally always use nano, because I find its commands simpler than something like vim, which is often the default editor. If you want to use nano as well, you can access the file to edit it with:
- sudo nano apps/qubit/config/settings.yml
If you don't have nano installed, you can install it with:
- sudo apt-get update
- sudo apt-get install nano
With nano, once you've made your changes, use CTRL+O to write the changes, press enter to preserve the file's current name, and then CTRL+X to exit.
Additionally, if you change any of the configuration files, you need to restart PHP-FPM for the changes to take effect. From your post in the forum, I'm wondering if this might be the step you missed previously? In Ubuntu 18.04 with PHP 7.2, you can run the following:
- sudo systemctl restart php7.2-fpm
With Ubuntu 16.04 and PHP 7.0, use:
- sudo systemctl restart php7.0-fpm
At this stage, I also recommend clearing the application cache. If you are using an additional caching engine such as memcached, restart that as well (you can try the command, it won't do any harm if you don't have memcached installed, it will just tell you):
- php symfony cc
- sudo systemctl restart memcached
You will also need to re-index the site content now that you have a new default culture:
- php symfony search:populate
Before you test, don't forget that your browser also has its own cache. You should clear this as well - or at least test in an Incognito or Private browser window, where the browser cache is typically disabled by default.
One important thing to note when verifying if the change has taken effect: changing the default installation culture will NOT automatically translate your data. The changes you should see have to do with the text on the user interface elements - things like the browse menu labels, the facet headers on search pages, the button block labels on view pages, the labels in the Settings, etc. French has good coverage in AtoM provided by our volunteer translator community (you can see the list of translated languages and the status of the translations here, and learn more about how to contribute translations here), but remember that not all languages have full coverage. AtoM uses what is known as culture fallback - so in places where there is no translated string provided, the inteface will "fall back" to displaying the default English string (rather than displaying nothing).
Keep in mind as well that if you create a bunch of descriptions in the English interface, then change the culture of your site, even if you wrote the content in French, in the database those descriptions have a culture of en listed - because you created them while in the English UI! Consequently the source culture in the database of your descriptions will be listed as English, even if the actual content was written in a different culture. I think you would need to use SQL to change this directly in the database. If you had English as your installation culture, but actually wrote your descriptions in French while using the French interface, then everything should be fine.
Finally, at this time, English cannot be fully removed from the language menu in AtoM - because that is the source language of all the user interface elements and the underlying code. As Corinne noted in her original response, you can hide the entire language menu from view, via Admin > Settings > Default page elements. See:
I hope this helps you and other users!
Cheers,
Dan Gillean, MAS, MLIS
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/f087e56f-569e-46c1-af5a-0bb499a9c91f%40googlegroups.com.
Samuel Bancal
Feb 10, 2020, 8:50:06 AM2/10/20
to AtoM Users
Hi Dan,
I really thought that post would help us solve our question ... surprisingly it's not the case, yet.
We had AtoM 2.4 on Ubuntu 18.04 that was installed with default language (or default "culture") in English.
We just installed a new server (U18.04 again), with AtoM 2.5 and migrated the DB, /usr/share/nginx/atom/uploads/ and /usr/share/nginx/atom/downloads/ to it. Globally, the setup seems to work fine.
But now, our archivist ask us to switch globally AtoM to French for the UI ... and everything.
Already on previous install, they saved all the archives in the French UI, but exporting it was not working as expected (only fields that are not related to a linguage were exported to CSV).
For this, I followed the steps you mention in this post (2019-10-01) ... But browsing the AtoM site, even with a Private browsing lead us to the default English language (even on a French OS with a browser that has French as preferred language).
And second part of our question ...
When doing an extraction (CSV), only the fields that aren't related the the language have a value (e.g. referenceCode, legacyId, parentId, identifier, ...) . The other (that were written originally with the UI in French) are left empty (e.g. title, scopeAndContent, ...). Additionally, we see in the same extraction the column "culture" with the value "en" (we thought it would have been "fr") !?
Do you have any idea what would be missing to set globally the language to French, and have the export work also in French?
Thanks,
Samuel
To unsubscribe from this group and stop receiving emails from it, send an email to ica-ato...@googlegroups.com.
Dan Gillean
Feb 10, 2020, 12:49:02 PM2/10/20
to ICA-AtoM Users
Hi Samuel,
There are a couple factors at play here. First, is the data in your database.
I think it might be worth checking to see whether or not the descriptions are in fact saved with an fr culture. If you created them manually via the user interface while in the French display, then they should have been saved as French descriptions. However, if you imported them, and you didn't add fr to the culture column, then there is a chance that AtoM defaulted to using en as the source culture.
We could use a SQL to check whether there are descriptions in your database saved with a French culture. To use the query, we will first need to access the MySQL command prompt. To do that, we will need to know the MySQL username, password, and database name used during installation.
If you can't recall for certain what credentials you used, you can always check in config/config.php - for example, to see this file you could run the following from the root AtoM installation directory, which should be /usr/share/nginx/atom if you have followed our recommended installation instructions:
- sudo nano config/config.php
- sudo cat /root/.my.cnf
- mysql -u root -proot atom;
Notice that there is a space between the -u and root, but NOT between the -p and the root password. Alternatively, you can leave no password following the -p, and you will be prompted to enter it by the command prompt before proceeding.
At this point, we should have access to the MySQL command prompt, which should look like this:
mysql>
Now we can try the following SQL query, which should return a count of all the descriptions you have in French:
- SELECT COUNT(*) FROM information_object_i18n WHERE culture='fr';
If nothing is returned, then this suggests that, for whatever reason, your descriptions are not actually saved in the database as French. We could likely use a SQL query to update these, but I will need a little help from our team to craft that query, so let me know if this is needed.
Second, the export itself:
Unfortunately, we've discovered some issues with secondary language CSV exports from the clipboard, captured in the following issues:
We also have this Wishlist ticket to enhance the language options on the Clipboard export page:
We've previously roughly estimated this Wishlist ticket at about $6,000 for us to implement - these numbers are bit old so I would want our team to review them, but that should give you a sense of the range of work required. We would need to address the bugs listed above as well, so a full solution would likely be in the $8-10K range?
In the meantime, it seems that a CSV export from the command-line will include all languages (including translations). See this related user forum thread:
It looks like you can use the --criteria option to export only descriptions of a particular culture like so:
- --criteria="i18n.culture='[CODE]'"
Replace [CODE] with the 2-letter ISO 639-1 language code for the culture you want to export.
So, for example, you could export all your French descriptions to a CSV called fr-content.csv with a command like this, replacing the path with an actual path to where you want the CSV to be exported:
- php symfony csv:export --criteria="i18n.culture='fr'" /path/to/location/of/fr-content.csv
Hope this helps! And, if this is a priority issue for your institution and you might be willing to sponsor work to improve our CSV import and internationalizaiton settings, please feel free to contact me off-list.
Cheers,
he / him
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/da2c1fe6-3da9-4abf-9fad-e7e592d67035%40googlegroups.com.
Samuel Bancal
Feb 11, 2020, 9:45:12 AM2/11/20
to AtoM Users
Hi Dan,
Thank you for your detailed answer.
I could have a look to the content of the DB ... it seems culture is set correctly :
mysql> SELECT COUNT(*) FROM information_object_i18n WHERE culture='fr';
+----------+
| COUNT(*) |
+----------+
| 13778 |
+----------+
I tried the export from CLI as you suggested ... it works as we expected : fields have the content and culture is set fo 'fr'.
We tried also to export as XML ... and again it works as expected.
I'm not sure to understand enough yet the issues you refer to. Would that mean that export to CSV will not work on data that were saved with culture='fr'? We know the existence of other archive sites in French where that works ... That's a bit surprising.
In the mean time, I could fix the 1st question (set the default language to French) ... by running the same commands I tried yesterday, plus restarting nginx. I don't know what I did wrong ... but glad it works now.
Cheers,
Samuel
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/da2c1fe6-3da9-4abf-9fad-e7e592d67035%40googlegroups.com.
Dan Gillean
Feb 12, 2020, 4:21:41 PM2/12/20
to ICA-AtoM Users
Hi Samuel,
I'm glad to hear that my suggestions helped you resolve the issues, and find a suitable workaround. Thanks for updating the thread to let us know!
I'm not going to speculate on why some AtoM sites might be behaving differently - internationalization (i18n) of applications is complex work that is affected by a number of factors. It may have to do with the fact that they didn't change the installation culture; with how they running exports; with how the data was created in the first place, and more. Instead, I just wanted to let you know about some known issues we have identified with multilingual exports via AtoM users interface, and some possible workarounds available to you until we can find someone willing to sponsor some improvements!
Either way, glad to hear you've gotten things resolved in your installation.
Cheers,
he / him
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/29a47e9c-ceb1-4b68-8d38-2c2a678d0e02%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages