Hi In opac-search.pl and search.pl, language names in the dropdown list are always in english (+ native name), even in your GUI is translated in an other language : Arabic, Bulgarian, etc. Mathieu Saby Rennes 2 University
Created attachment 12997 [details] [review] [PATCH] Bug 8954: Make languages list in advanced search translatable In opac-search.pl and search.pl, this patch moves the $lang variable from the end to the begining of the script, and use it as a parameter of getAllLanguages method. To test, set your opac and staff interface in english and in other languages and check search.pl and opac-search.pl : - If language names in your languages_description table are translated in the same language you use for your GUI, the language names in dropdown list will be translated in this language (+native name). - If your GUI is in english, or in a language into whitch languages names are not translated in languages_description, the dropdown list will stay in english (+native name). Mathieu Saby Rennes 2 University
After applying this patch and switching from English to French I see no languages at all. From the output of the OPAC page: <select id="language-limit" name="limit"> <option value="">Sans limite</option> <option value="ln,rtrn:"></option> <option value="ln,rtrn:"></option> <option value="ln,rtrn:"></option> The languages do appear as before when I'm in English mode.
Thank you for testing. That's bad... I will try to correct that this afternoon. M. Saby
Why it is not working : 1. in C4/Languages.pm, the sub getAllanguages can get a parameter, whose value is assigned to the variable $current_language. If no parameter, $current_language gets the value 'en'. Then the sub search for $current_language in "lang" column of language_descriptions table. If $current_language does not match any value in this column, the sub does not search english language name (as I thought.). So no languages are showing in the resulting list in html. 2. In this table, the only 2 values in lang colum are currently "en" and "fr". But in opac-search.pl and opac-pl, I pass as a parameter the value given C4::Templates::getlanguages. For a french template, it is "fr-FR", and not "fr". So it is more complicated as I first thought, and I don't know how to resolve these 2 issues for the moment. If somebody has an idea... Mathieu Saby Rennes 2 University
Created attachment 13127 [details] [review] Proposed patch 2 I added truncation of $lang to get two first characters. Same behavior exists in Search.pm for stemming. You can test and sign-off.
Thank you Fridolyn. I was considering either your solution, or to change the "fr" to "fr-FR" in the database... I will test, and check if it works in french translated interface. I suppose there will probably still be a problem if koha interface is translated in an other langage. I'll check and make an other corrective patch if needed. Mathieu Saby Rennes 2 University
(In reply to comment #6) > I suppose there will probably still be a problem if koha interface is > translated in an other langage. Yes, your right. I think we should make a query on both $lang and 'en' and use the first result.
Created attachment 13332 [details] [review] [PATCH] Bug 8954: Make languages list in advanced search translatable (revision 1) In fact, RFC4646 codes could sometimes contain 3 letters (for example, "tet" for Tetun, a language into which Koha is translated...). So I think the best is to use regex_lang_subtags function, defined in C4/Languages.pm. Description of this new patch : In opac-search.pl and search.pl, this patch moves the $lang variable from the end to the begining of the script, and use it as a parameter for getAllLanguages. In Languages.pm, getAllLanguages function is modified : - if no parameter is passed to the function, it returns english languages names - if a $lang parameter conforming to RFC4646 syntax is passed : -- the function returns languages names translated in $lang if possible -- if a language name is not translated in $lang in database, the function returns english language name To test, set your opac and staff interface in english and in other languages and check search.pl and opac-search.pl : - If language names in your languages_description table are translated in the same language you use for your GUI, the language names in dropdown list will be translated in this language (+native name). - If your GUI is in english, or in a language into whitch languages names are not translated in languages_description, the dropdown list will stay in english (+native name). Mathieu Saby Rennes 2 University
Created attachment 13371 [details] [review] [SIGNED-OFF] Bug 8954: Make languages list in advanced search translatable (revision 1) In opac-search.pl and search.pl, this patch moves the $lang variable from the end to the begining of the script, and use it as a parameter for getAllLanguages. In Languages.pm, getAllLanguages function is modified : - if no parameter is passed to the function, it returns english languages names - if a $lang parameter conforming to RFC4646 syntax is passed : -- the function returns languages names translated in $lang if possible -- if a language name is not translated in $lang in database, the function returns english language name To test, set your opac and staff interface in english and in other languages and check search.pl and opac-search.pl : - If language names in your languages_description table are translated in the same language you use for your GUI, the language names in dropdown list will be translated in this language (+native name). - If your GUI is in english, or in a language into whitch languages names are not translated in languages_description, the dropdown list will stay in english (+native name). Signed-off-by: Marc Veron <veron@veron.ch> Patch behaves as expected. With Opac language set to French I got all languages with French language name. With German (de-DE), I got only a few with German language names (and all other with English ones), this was due to missing entries for de-DE in table language_descriptions. This behaviour is consistent with the description above.
Created attachment 13502 [details] [review] [SIGNED OFF] Bug 8954: Make languages list in advanced search translatable (revision 1) In opac-search.pl and search.pl, this patch moves the $lang variable from the end to the begining of the script, and use it as a parameter for getAllLanguages. In Languages.pm, getAllLanguages function is modified : - if no parameter is passed to the function, it returns english languages names - if a $lang parameter conforming to RFC4646 syntax is passed : -- the function returns languages names translated in $lang if possible -- if a language name is not translated in $lang in database, the function returns english language name To test, set your opac and staff interface in english and in other languages and check search.pl and opac-search.pl : - If language names in your languages_description table are translated in the same language you use for your GUI, the language names in dropdown list will be translated in this language (+native name). - If your GUI is in english, or in a language into whitch languages names are not translated in languages_description, the dropdown list will stay in english (+native name). Signed-off-by: Marc Veron <veron@veron.ch> Patch behaves as expected. With Opac language set to French I got all languages with French language name. With German (de-DE), I got only a few with German language names (and all other with English ones), this was due to missing entries for de-DE in table language_descriptions. This behaviour is consistent with the description above. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Tested language list in OPAC and staff advanced search is translated properly after applying the patch. Checked that language switcher still works like it should. http://bugs.koha-community.org/show_bug.cgi?id=9056
Comment on attachment 13371 [details] [review] [SIGNED-OFF] Bug 8954: Make languages list in advanced search translatable (revision 1) Adding another sign-off. This patch includes no string changes.
Marc & Katrin, thank you for signing off! Mathieu Saby
QA comment: * C4/Language.pm is the dirtiest code we've into Koha. It does hundreds of SQL queries on each page. That must be THE place to optimize after 3.10 (I plan to try to do something for that). This patch add more SQL, that's bad, but I've no counter proposal, so it's OK * passes koha-qa.pl * works as announced passed QA
Created attachment 13558 [details] [review] Bug 8954: Make languages list in advanced search translatable (revision 1) In opac-search.pl and search.pl, this patch moves the $lang variable from the end to the begining of the script, and use it as a parameter for getAllLanguages. In Languages.pm, getAllLanguages function is modified : - if no parameter is passed to the function, it returns english languages names - if a $lang parameter conforming to RFC4646 syntax is passed : -- the function returns languages names translated in $lang if possible -- if a language name is not translated in $lang in database, the function returns english language name To test, set your opac and staff interface in english and in other languages and check search.pl and opac-search.pl : - If language names in your languages_description table are translated in the same language you use for your GUI, the language names in dropdown list will be translated in this language (+native name). - If your GUI is in english, or in a language into whitch languages names are not translated in languages_description, the dropdown list will stay in english (+native name). Signed-off-by: Marc Veron <veron@veron.ch> Patch behaves as expected. With Opac language set to French I got all languages with French language name. With German (de-DE), I got only a few with German language names (and all other with English ones), this was due to missing entries for de-DE in table language_descriptions. This behaviour is consistent with the description above. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Tested language list in OPAC and staff advanced search is translated properly after applying the patch. Checked that language switcher still works like it should. http://bugs.koha-community.org/show_bug.cgi?id=9056 Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>
@Paul : Regarding languages in Koha, I don't understand why we have a list in authorized values, AND an other list made of THREE tables. It is a nightmare to understand, to test, to correct and to improve. Not to speak of internationalisation! For example, I wanted to create a new facet for languages. But what list should I use ? The list in authorised values is not translatable, but the 3-tables-list is more complete, and translatable (in the HARD way : adding new names in sql tables). Mathieu
Oups, of course, I mean the 3-table list is less complete than the authorized values list. Mathieu
Hi Mathieu, I think the LANG authorised value might be specific to UNIMARC. There is no sample data for language codes for German or en (afaik). The good thing about language is, that they are pretty static. So perhaps the sql tables are not that bad and when someone tells us about a missing language or translation we can help getting it right. I think one of the bigger problems we have with the sql data is, that we need one file for each translated installer - that's horrible to maintain. There should be one central file for all lanugages (see discussion on bug 9056)
Thank you Katrin I think in french unimarc the LANG authorised values are used - for cataloguing - for "translating" iso codes into french when koha display a record in opac and in staff interface. So I thought it was universal... I will take a look at bz9056 Mathieu
This patch has been pushed to master. I fixed a small typo in the POD (a missing semicolon) when pushing.
Patch pushed to branch 3.10.x
Pushed this fix to 3.8.x also, will be in 3.8.8
Pushed to 3.6.x will be in 3.6.11.
Created attachment 13860 [details] [review] [SIGNED-OFF] Bug 8945: Did you mean help file Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Marc Veron <veron@veron.ch> Help displays as expected on page koha/admin/didyoumean.pl
Hi Marc, I think you had a little typo in the bug number- could you attach your signed off patch to 8945? Thanks!
Comment on attachment 13860 [details] [review] [SIGNED-OFF] Bug 8945: Did you mean help file I see now, that this has already been done - obsoleting wrong patch here :)
Sorry, it was late... :-)