http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4447 --- Comment #1 from Jane Wagner <jwagner@ptfs.com> 2011-03-28 13:25:20 UTC --- Revisiting this issue. Henri-Damien's work in the referred-to message has not been finished. It's a promising approach (allowing for inclusion of a URL in the existing staff and OPAC XSLT sysprefs): + my $style_doc; + if ($xslfilename=~/http:/){ + my $xsltstring=GetURI($xslfilename); + $style_doc = $parser->parse_string($xsltstring); However, current code seems to have moved past the point at which the patch was written. The current code building the name of the relevant XSLT file now includes a language directory. For example: $xslfile = C4::Context->config('opachtdocs') . '/' . C4::Context->preference("opacthemes") . '/' . C4::Output::_current_language() . '/xslt/' . C4::Context->preference('marcflavour') . "slim2OPAC$xsl_suffix.xsl"; To prevent problems with translations, should the syspref only take a URL that goes to a directory level? Then, on the remote server, replicate the directory structure so that there is an en/MARC21slim2OPACDetail.xsl, fr/MARC21slim2OPACDetail.xsl, es/MARC21slim2OPACDetail.xsl etc. etc.? Also note the check for the themes directory in the above, which was hardcoded to "prog" in the earlier code. Should the remote directory structure be further amplified to be prog/en/MARC21slim2OPACDetail.xsl etc.? What would be the most flexible setup that would still allow for translations and (whenever it's implemented) different themes? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.