English XSLT contains constructs as: <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">at</xsl:with-param> </xsl:call-template> The translated Dutch XSLT contains: <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">bij</xsl:with-param> </xsl:call-template> Since at is not a word here, but just two subfields a and t, they should not have been translated of course. Incidentally, bij is the Dutch translation of the English at. The word gets translated and so subfields a and t are replaced by b, i and j. In most cases resulting in no information. Note: Occurs 5 times in MARC21slim2OPACDetail.xsl. And affects display of fields 490/8XX, 773, 780/785.
I have run into this exact problem too. The problem is not solved by just not translating it, because other files include an 'at' that you want to have translated.
Yes, it is very hard for the script to know that at is not a word, but 2 subfields. I dont have a solution, maybe Frederic does.
(In reply to comment #1) > I have run into this exact problem too. The problem is not solved by > just not translating it, because other files include an 'at' that you > want to have translated. Where exactly? I have just one msgid "at" extracted from .xsl files. No extraction from .tt files.
Ah, I am sorry. I noticed this in one of the older versions, probably 3.2.x and forgot to check 3.4. Perhaps this has been solved by a change to the templates.
Sending a patch: This patch resolves the situation of translating the parameters at (meaning subfield a and t) of subfieldSelect by replacing at with a_t. This string will not be translated and the xslt function subfieldSelect just ignores the underscore. It is a pragmatic and easy solution. Theoretically, we should look for a solution in the translation parser. This is much harder and would probably not result in better code in those modules.
Test this patch with the following remarks in mind: 1) This patch deals with XSLT. So you should enable XSLT at OPAC detail. 2) In English or any language not translating the word at: Just check if the links for a MARC 490, 773, 780 or 785 still work at the opac detail page. 3) For a language translating the word at (like Dutch where at becomes bij), you should first rerun your translation process (at least for the OPAC). 4) In that language: Check the results on the vernacular opac detail page for MARC 490, 773, 780 or 785. Without the patch, you would not see a link following e.g. the Series label (with 490 first indicator set to 1). With the patch, you should see a link now.
Created attachment 5248 [details] [review] Patch
Created attachment 5488 [details] [review] [SIGNED-OFF] 6278 Funny translation bug with XSLT subfieldSelect parameters This patch resolves the situation of translating the parameters at (meaning subfield a and t) of subfieldSelect by replacing at with a_t. This string will not be translated and the xslt function subfieldSelect just ignores the underscore. It is a pragmatic and easy solution. Theoretically, we should look for a solution in the translation parser. This is much harder and would probably not result in better code in those modules. Test this patch with the following remarks in mind: 1) This patch deals with XSLT. So you should enable XSLT at OPAC detail. 2) In English or any language not translating the word at: Just check if the links for a MARC 490, 773, 780 or 785 still work at the opac detail page. 3) For a language translating the word at (like Dutch where at becomes bij), you should first rerun your translation process (at least for the OPAC). 4) In that language: Check the results on the vernacular opac detail page for MARC 490, 773, 780 or 785. Without the patch, you would not see a link following e.g. the Series label (with 490 first indicator set to 1). With the patch, you should see a link now. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Pragmatic solution for an annoying problem.
QA comment: well, this is a very small patch, that circumvent a "funny" problem, I agree. This is a workaround, but I agree with katrin it's an easy & pragmatic solution. I vote for "passed QA", but i let ian/chris the "final cut" on this matter, as it's a workaround.
I have no issues if you want to push this through QA.
Ian, please, confirm you agree with chris & me about accepting this workaround
If the subfieldSelect routine ignores underscore and that'll prevent translation, this seems like a very easy and acceptable workaround. Marking as Passed QA.
Changes templates, but actually reduces translation needed, pushing