Internationalized Omeka S

HI Hajoki,

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.

Paul

@hajoki There’s now a branch of CSVImport working on being able to assert language values when mapping property data from CSV columns https://github.com/omeka-s-modules/CSVImport/tree/language-mapping

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.

Sure, I see, thank you for giving it a thought anyway!

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?

Thank you for your future examples and insights.

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.

Hello there,

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); ?>

Good luck to all!

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?

That’s a fantastic question/feature request. I’ve added it to the omeka s issues for consideration. https://github.com/omeka/omeka-s/issues/1060

Great! I was thinking that attaching a language label to the whole URI (URI label + link) and not just to the URI label would actually give more flexibility.

Another related idea and again I have no idea if this is feasible or not:
would it be possible to enter in a csv file both an URI and its label in two different columns?
At the moment, I can import the column containing the links as URI but cannot import the column containing the labels, right?

A general question: so would the best way to handle the multilingual issue still be to have the parallel sites managed within Omeka-S? I’ve just installed it in part to do this… we have a bilingual English-Chinese site. Have no problem working on the Transifex for Chinese (I signed up a while ago) if this is the case.

I think where we are at the moment with S, the best option is parallel sites. The items can be shared and each item can have multilingual values, but the site’s content is single-language. To support this workflow, each site can have its own Locale setting for choosing translation language, date display, and so on.

The locale setting could be used for other things (like choosing which metadata values to show or prioritize), but in the current stock themes we’re not doing that.

1 Like

Thanks @jflatnes I think that’s what we’ll do - we don’t need the site content to be changed. Right now we use the Item Relations plug-in in Omeka Classic for that anyways - and only on a few documents. The vast majority of our content will remain in only one language. We just need the rest to be localized because some of our users (as we’re finding out) can’t navigate or read the metadata in English very well at all.

A post was split to a new topic: Omeka S translation questions