I bumped into a rather strange and obscure bug when using the 'Korean' language in staff Here are the steps to replicate... 1/ set you lang to 'en' 2/ do a member search on any string (that returns multiple results) observe that results are displayed OK (see pic 1) 3/ set your language to Korean 4/ repeat step 2, and observe the following datatables error, (see pic2) "DataTables warning: table id=memberresultst - Requested unknown parameter 'dt_cardnumber' for row 0. For more information about this error, please see http://datatables.net/tn/4" I noticed that the error does not occur using the 'french' language (see pic 3) Bug discovered in 3.20.6 - i've not confirmed in master (yet)
Created attachment 49506 [details] pic 1
Created attachment 49507 [details] pic 2
Created attachment 49508 [details] pic 3
(In reply to Mason James from comment #0) > I bumped into a rather strange and obscure bug when using the 'Korean' > language in staff > > Here are the steps to replicate... > 1/ set you lang to 'en' > > 2/ do a member search on any string (that returns multiple results) > observe that results are displayed OK (see pic 1) > > 3/ set your language to Korean > > 4/ repeat step 2, and observe the following datatables error, (see pic2) > > "DataTables warning: table id=memberresultst - Requested unknown parameter > 'dt_cardnumber' for row 0. For more information about this error, please see > http://datatables.net/tn/4" I imagine there may be other similar datatable errors, using other languages in Koha
It's a translation issue: 130 #. %1$s: END. 131 #. %2$s: data.cardnumber | html. 132 #: intranet-tmpl/prog/en/modules/members/tables/members_results.tt:12 133 #, c-format 134 msgid "\", %s \"dt_cardnumber\": \"%s\", \"dt_name\": \"" 135 msgstr "\", %s \"dt_카드숫자\": \"%s\", \"dt_이름\": \"" dt_cardnumber and dt_name should not have been translated.
(In reply to Jonathan Druart from comment #5) > It's a translation issue: > > 130 #. %1$s: END. > 131 #. %2$s: data.cardnumber | html. > 132 #: intranet-tmpl/prog/en/modules/members/tables/members_results.tt:12 > 133 #, c-format > 134 msgid "\", %s \"dt_cardnumber\": \"%s\", \"dt_name\": \"" > 135 msgstr "\", %s \"dt_카드숫자\": \"%s\", \"dt_이름\": \"" > > > dt_cardnumber and dt_name should not have been translated. aah yes, of course! folks, what's the best way for me to correct this typo? i can't seem to correct this typo via 'pootle', is it possible?
As the error is in the po file, it can be corrected via Pootle - but you might not be able to submit your change directly, depending on permissions. Maybe bring it to the koha-translate mailing list?
Created attachment 49868 [details] [review] Bug 16144: Remove 'dt_*' from translation strings when possible This patch removes strings form translation files that have 'dt_*' variables besides puntuation, html constructs, etc. To test: 1) Update strings for any language 2) Check for strings with 'dt_*', eg. for es-ES msgcat --no-wrap po/es-ES-staff-prog.po | egrep ^msgid | egrep "dt_" 3) Apply the patch & update again 4) Compare similar strings, there are now a few less strings This does not remove all occurrences, there's no easy way to do that.
Created attachment 49869 [details] [review] Bug 16144: Remove 'dt_*' from translation strings when possible This patch removes strings form translation files that have 'dt_*' variables besides puntuation, html constructs, etc. To test: 1) Update strings for any language 2) Check for strings with 'dt_*', eg. for es-ES msgcat --no-wrap po/es-ES-staff-prog.po | egrep ^msgid | egrep "dt_" 3) Apply the patch & update again 4) Compare similar strings, there are now a few less strings This does not remove all occurrences, there's no easy way to do that.
My patch remove some of the problematic strings, but not all. To fix this you need to edit translation file in pootle, I can help to identify those strings.
Bernardo, I don't know if we should manage these kind of exceptions. Especially when it does not catch all the strings.
(In reply to Jonathan Druart from comment #11) > Bernardo, I don't know if we should manage these kind of exceptions. > Especially when it does not catch all the strings. I think you are right, it only catch ~5 strings. Switch to wontfix?
(In reply to Bernardo Gonzalez Kriegel from comment #12) > (In reply to Jonathan Druart from comment #11) > > Bernardo, I don't know if we should manage these kind of exceptions. > > Especially when it does not catch all the strings. > > I think you are right, it only catch ~5 strings. > Switch to wontfix? If it has been fixed on pootle, we can mark it as resolved.
(In reply to Jonathan Druart from comment #13) > > If it has been fixed on pootle, we can mark it as resolved. Yes, those entries have been marked as fuzzy on pootle for 3.20 & 3.22