We would like to make our Omeka S website available in 3 languages and I had several questions connected to each other, on:
The structure of the site: is it the right way to go to create items once, with fields duplicated 3 times, one attributed to each language, and to display the items on three different sites, one for each language?
The translation of personal content: as for now, when one fills a field (e.g. a title) for several languages, all the languages are displayed on the page. It seemed to be a first step to show international content (Bilingual content/internationalisation), have other possibilities already been explored?
The module CSV Import: could we imagine a way to refer to a field in a certain language so that the mapping with a CSV file would attribute the language label to that field? As for now, I can import 3 title fields with a csv file, but I have to attribute the language manually.
The translation of Omeka S navigation: has a Transifex project already started to make Omeka S navigation elements available in several languages?
The treatment of tags: has the presence of tags been completely abandoned in Omeka S or is it replaced by another system? What is the envisaged solution in case of multiple-language tags?
My questions mostly aim at checking what is now available, what has been tested and what is worked on at the moment by others to have an idea of what to try to develop on our part.
Thank you in advance for your answers!
Good questions. I’ve been thinking about them more and more lately as we get closer to another beta release (and as I notice places in my own code where I haven’t added internationalization!). Hopefully other people on the dev team will fill in where I miss things or get things wrong.
Structure: yes, the idea is to use the language setting when entering properties. We’re pushing toward official language codes there, but there might be some grey area.
Personal content: I think that practice is still a bit open. I’m guessing that a theme could add a switch for which language to display. How to set that without duplicating the same theme for each language is a good question, as you saw in the previous forum post you linked to.
CSV Import: An excellent and timely feature request. I’m adding another feature related to property data this week in preparation for a new beta release. It makes sense for me to add this, too. It’d be another option on the mapping page under the option to assert that a mapping contains a URL reference.
Transifex: Not sure, but if not it seems like we’re getting close to doing so, and checking how well our i18n is covered in core and modules (like I said, I know I’m missing places, including in CSV Import)
Tags: I’m pretty sure we’re going with no tags, and instead using dcterms:subject or whatever other property you want to handle that.
Thank you very much for all these answers and for your concern about this issue!
Do you have any prevision for the date of the new beta release or the launch of the Transifex translation?
We (Digirati) will be adding internationalisation features to the Omeka S project we are building for the National Library of Wales, probably starting that part of the work in a few weeks time.
The basic requirement is that a user is able to switch between languages at any time, and both content items and site navigation are available, usually in two languages (Welsh and English) but sometimes more than two.
Although we haven’t started development on this part yet, we imagine that this internationalisation functionality would be implemented as a module.
It would be great to hear from anyone who is working (or thinking of working) on something similar, maybe to compare approaches or determine good/best practice? I’ll share more detailed requirements/implementation thoughts here as soon as I can.
Nice initiative Tom, we are also interested in sharing concerns and good practices in this topic.
To talk also a bit about our project, we are transforming the visual archives of the French Institute for Anatolian Studies: http://ifeaistanbul.net/photodatabase/, in particular turning from Omeka 2 to Omeka S.
Our requirements are that the website would be available in English, French and Turkish (navigation, description of images and tag cloud) with the ability for the user to switch languages at any time, within the next four months (July 2017).
We now store our items once with three times duplicated fields imported with CSV files, as for now we are manually setting the language but we welcome the future possibility to do the mapping with CSV Import with great interest.
We are ready to help for the Transifex translation of Omeka S, especially as French or Turkish might not be among the first languages that will come up. Do you advise that we open a project now?
As for the display of only one language by site and the possibility to switch between languages, we are prospecting and not set yet on something, Patrick suggests a theme, Tom you talk about a module, do you know what has been adopted for this website of the National Library of Wales: http://cymru1914.org/? Have you heard of other examples of multilingual Omeka S websites?
Thank you in advance for your insights and good luck with your projects as well.
Cymru1914 was not built on Omeka, its built around a Solr core with a custom PHP (codeigniter) frontend. All our websites have to be bilingual, so this approach where the user can choose their own language is on all NLW sites.
It seems pretty stable so far, but if you have live data (as opposed to my fake data) that you’d like to try against that branch, feedback would be greatly appreciated.
Thanks a lot, tried it and it worked just fine!
In the future, could we even imagine detecting the language labels from the CSV file directly, in the same way that a “dcterms:title” entitled column is detected as containing a Title?
But this add-on already helps a great deal!
I thought about that, too. I think it’s possible, but would call for a specific way to parse the data apart, and defining a specific format for it (probably something like dcterms:title@lang=de). Then, it’d have to handle checking whether it’s a valid language code, and to have a good UX signaling when there’s an invalid code. So, the complications build up pretty quickly going down that route.
Hello everyone,
How are Omeka S multilingual projects going? We are curious to hear your developments and exchange ideas.
Our project of trilingual photo database became three symmetrical sites presenting the same items and items sets, one for each language, with the language label as site slug (fr, tr, en).
That way, we can retrieve the current locale from any page (cf [solved] How to find current page slug in theme) and rebuild the url to arrive exactly on the same page with the desired language if needed. We added a language switcher in the header (layout.phtml) in our theme so that switching is possible from any page.
We store the metadata of our items in csv files, where a field present in 3 languages is represented by 3 columns, to which we attach the language label thanks to the fork language-mapping of the CSV import module suggested above (https://github.com/omeka-s-modules/CSVImport/tree/language-mapping).
Then we display only the metadata in the language of the locale indicated by the site slug (by modifications on AbstractResourceEntityRepresentation.php).
Tags become “dcterms:subject”s, field that we set as searchable with the Metadata browse module, and independent for each language.
Unfortunately when it makes more sense to attach description to the media than to the item, the field has to be filled manually in the three languages but it still serves our purposes (cf Metadata for Media / Item set with CSV Import module?)
Stay some elements proper to Omeka S not yet translated. We generated a file with Poedit with the elements to translate we could collect on our website, but how could we start an open Transifex project to translate them?
Where could we obtain the .po files from Omeka 2, that could help for the translation of some elements?
Thanks. We’re moving into that step of interface work and sending it to Transifex (https://github.com/omeka/omeka-s/issues/885) , which is probably the first step toward internationalization.
The more complex, user-centered, work I think we’re still uncertain about. I’ve been convinced that that works best as a user-chosen setting, put into session data. The question is where there that should happen – a module or core. Personally, I lean toward trying to figure out how to put that in core somehow, then letting themes and modules always have access to that. However, I suspect that’d be fairly complex, and I have a bad reputation for gravitating to the most complex options!
What I’d ideally like to avoid is having a multilinguage site depend on the redirects to different sites that you describe. It’s a reasonable solution, but I’m still hoping we can figure out something that differentiates content more fluidly within one site, using the language setting. Still not sure if that’s possible, or the direction we’ll take, but it’s among the things on my mind.
Following the opening of the project Transifex for Omeka S (https://www.transifex.com/omeka/omeka-s/), I have one practical question: what one should do so that a file .po corresponding to a new language, placed in application/languages/ is taken into account?
And a more general question, maybe linked to the previous one: what are the directions taken by Omeka S on multilingualism at the moment?
I saw that the possibility of one language parameter for each site could appear without being the only option (https://github.com/omeka/omeka-s/issues/972),
and that the treatment of languages for tags will depend on the main mechanism chosen by Omeka S (https://github.com/Daniel-KM/Omeka-S-module-Folksonomy/issues/2),
but the discussion in the github issue gets a bit hard to follow (https://github.com/omeka/omeka-s/issues/898).
A bit of prospective on the topic would be most welcome, thanks in advance!
As for a .po file: you’d first need to convert it to a .mo using Gettext’s msgfmt. When Omeka S does a release, we’ll pull in everything that’s on Transifex (over a certain completion percentage), and we’ll do the compilation/conversion as well. I’ll also add a gulp task for compiling everything in the languages folder (this is a good reminder for me to do so).
With the .mo in place, you can use it by setting the appropriate locale in config/local.config.php.
Thanks for the answer, I could generate the .mo files from the .po files with PoEdit. My problem now is that I am working on a single Omeka S installation with one site per language: changing the locale in config/local.config.php affects the three sites. Is there a solution for such a case?
Hello everyone,
I saw the issue on having a language parameter per site was closed, does it mean this proposition is turned down or already included?
Are there any news about how Omeka plans to deal with multilingualism or any evolving multilingual Omeka S sites?
Just sharing the solution I could find to get text included in the translate() instruction to be displayed in the correct language for each of my monolingual site, named after the language : I collect the language label from the URL in a variable $current_locale that I pass to the translate () instruction that way: <?php echo $this->translate('Items', 'default', $current_locale); ?>
There’s a per-site language selection (currently a drop-down menu selecting from the available translations in the site’s settings) in the current development code.
ok, thanks for the info!
Something else related to language but that might not be a priority: would it be possible to consider having multilingual labels for an URI?