members-update.tt has a giant hash variable that contains the borrowers database table fields, and their clear-text counterparts. This shows up in the po-files as one giant msgid, which is really ugly and unwieldy: msgid "" "%s %s [%% SET field_display_names = { surname => \"Surname\" firstname => " "\"First name\" title => \"Title\" othernames => \"Other names\" initials => " "\"Initials\" streetnumber => \"Street number\" streettype => \"Street type\" " "address => \"Address\" address2 => \"Address 2\" city => \"City\" state => " etc. for 20 more lines. This should probably be split into a separate tt include, and changed so only the translatable strings are picked up for translation.
Created attachment 30678 [details] [review] Bug 12222: members-update.tt has a giant hash variable This patch changes that giant hash by a TT block to find apropriate strings To test: 1) Apply the patch 2) On opac log as some user and request some modifications on personal data 3) On staff, reload main, will see a notice that a patron has requested modification, clic on the link 4) All modified data must show with apropriate legends for each db column, check for regressions 5) Update translation files for your preferred language, xx-YY Check for new strings, e.g. egrep "Alternate address" misc/translator/po/xx-YY* You must find old and new instances (old with #~ , in particular the hash one)
Changed Importance from enhancement to minor, from the perspective of translation this is a bug.
Created attachment 30682 [details] [review] Bug 12222: members-update.tt has a giant hash variable This patch changes that giant hash by a TT block to find apropriate strings To test: 1) Apply the patch 2) On opac log as some user and request some modifications on personal data 3) On staff, reload main, will see a notice that a patron has requested modification, clic on the link 4) All modified data must show with apropriate legends for each db column, check for regressions 5) Update translation files for your preferred language, xx-YY Check for new strings, e.g. egrep "Alternate address" misc/translator/po/xx-YY* You must find old and new instances (old with #~ , in particular the hash one) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Works as advertised, strings are now translatable.
I have problems testing this. When I try to send an update request, I have an error message: DBIx::Class::Row::new(): No such column 'B_email' on Koha::Schema::Result::BorrowerModification at /home/katrin/kohaclone/Koha/Borrower/Modifications.pm line 63
Should add... also happens on master for me, but can't check this works at the moment.
Created attachment 31074 [details] [review] Bug 12222: members-update.tt has a giant hash variable This patch changes that giant hash by a TT block to find apropriate strings To test: 1) Apply the patch 2) On opac log as some user and request some modifications on personal data 3) On staff, reload main, will see a notice that a patron has requested modification, clic on the link 4) All modified data must show with apropriate legends for each db column, check for regressions 5) Update translation files for your preferred language, xx-YY Check for new strings, e.g. egrep "Alternate address" misc/translator/po/xx-YY* You must find old and new instances (old with #~ , in particular the hash one) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Works as advertised, strings are now translatable. Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Works great with patch on bug 12623.
Patch pushed to master. Thanks Bernardo! I'd prefer to have the field names read from columns.def instead, please take a look at C4::Templates::GetColumnDefs. Important improvement anyway.