For libraries with multiple installed and enabled OPAC languages, the first enabled language in the list of activated languages is selected as default, not the primary language for the installation.
1. Install multiple OPAC languages
2. Active one that is 'higher' on the list than your native install language
3. Go to the OPAC, and see that that language, not your native language, displays
Root of the problem:
Line 57 of opac/opac-main.pl references "opac-main.tmpl", which no longer exists since the conversion to Template::Toolkit. Changing this to opac-main.tt fixes the issue.
How would you determine what is "the primary language for the installation"?
Koha is supposed to take the HTTP_ACCEPT_LANGUAGE variable passed by your browser, and use that to determine the right 'default' language (which is then overridden by whatever language you choose on your own and that is set in your cookie)... that seems like a pretty good idea for a default, since it favours the users local preferences, not one particular language pack. This doesn't seem to be the case in practice, however.
Hm, one way to do it might be to look at what language was chosen for Zebra
during Makefile.PL, but that limits it to 3 languages.
Another might be to use the language chosen during the web installer, but that
limits it to about 8 (I think).
And if I want to create an installation that has Norwegian Nynorsk as it's
primary language I would have to do the installation in Norwegian Bokmål,
because that is the closest one that is available.
I can't really see any way around adding actual sysprefs for the default
language in 1. the OPAC and 2. the staff client...
It'd probably be too much work, but if we could alter the system preference editor to allow one to drag/drop/reorder the languages and opaclanguages system preference to put their favourite first, I think that might also fix it.
I think that was like it worked before and I didn't like it much for some reasons.
It didn't respect activated languages from the system preferences and the language chooser is optional and often not activated. Sometimes people install languages, modify templates or add css files only to their language. So all I got to see were outdated, not properly working and quite ugly templates until I changed my browser settings.
I am in favor of adding a default language sys pref over automated detection of language.
If we want it to use the browser setting to detect the right language it should be limited to activated languages only.
Creating one or two system preference(s) looks like the best way for me too.
Now we have these preferences :
* language -> list of staff languages
* opaclanguages -> list of opac languages
To be consistent, we could then add :
* opacdefaultlanguage (or defaultopaclanguage ? )
Or names with upper cases ? How have the new preferences been named recently ?
Drawback: most of the time, these syspref will have the same value. But having only one could create issues (we could do with 1 syspref and add more checks to ensure that the default language has been selected in "language" and "opaclanguages", but I'm not sure it's the best way to go).
We have a library asking to offer the OPAC in English first. At the moment this is not possible when German templates are installed, because of the browser detection.
Perhaps we need a mechanism like:
If a default language is set, use that and overwrite browser detection.
If no default langauge is set, let browser detect and select language from list of activated (not installed) languages.
Is there already a browser detection implemented ?
In my case, if I have an OPAC with French and English languages, the English will appear first even if my browser is in French.
Yes, there is browser detection, although it was broken recently. Still waiting for the patch to go into 3.6.x (bug 7282)
Browser language detection and cookies appear to work correctly right now, but there is still no option to force Koha to another default language than English for fallback. Closing this duplicate of the earlier bug 6481.
*** This bug has been marked as a duplicate of bug 6481 ***