Summary: | Default OPAC language not set properly | ||
---|---|---|---|
Product: | Koha | Reporter: | Ian Walls <koha.sekjal> |
Component: | I18N/L10N | Assignee: | Ian Walls <koha.sekjal> |
Status: | RESOLVED DUPLICATE | QA Contact: | Bugs List <koha-bugs> |
Severity: | minor | ||
Priority: | P5 - low | CC: | adrien.saurat, f.demians, magnus |
Version: | 3.6 | ||
Hardware: | All | ||
OS: | All | ||
GIT URL: | Change sponsored?: | Sponsored | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: | ||
Bug Depends on: | 6755 | ||
Bug Blocks: |
Description
Ian Walls
2011-07-07 13:05:49 UTC
See also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6481 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2562 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 : * languagedefault * 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) |