Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localised url/urlfrom ignored as field format url hardcodes \mkbibacro{url} #1358

Open
cfr42 opened this issue May 24, 2024 · 6 comments
Open
Labels
documentation fixedindev Fixed in current DEV version

Comments

@cfr42
Copy link

cfr42 commented May 24, 2024

Please excuse me if I've misunderstood how this is meant to work.

As I understand it, url and/or urlfrom are localisable strings which are used to label URLs in e.g. bibliography entries.

However, the default format for field url hardcodes URL rather than using such a string.

\DeclareFieldFormat{url}{\mkbibacro{URL}\addcolon\space\url{#1}}

So setting urlfrom and url in the following has no influence over the result.

\documentclass{article}
\usepackage{biblatex}
\addbibresource{biblatex-examples.bib}
\DefineBibliographyStrings{english}{urlseen={Accessed on},urlfrom = {Available at},url={Available from}}
\begin{document}
\cite{ctan}
\printbibliography
\end{document}

This also means that the localised strings defined for this field in Biblatex's own .lbx files have no effect. For example, changing the document language to Dutch modifies visited on but not URL. To override the default, it therefore seems one has to redefine the field format:

\DeclareFieldFormat{url}{\bibstring{urlfrom}\addcolon\space\url{#1}}

According to the change history in the documentation, the original url format was restored in 2.6 and the urlfrom localisation key was added. This followed a change in 2.5 which localised url rather than hard-coding it. I take it this means that url is not a string which can be localised (though it briefly was), but that urlfrom is intended to provide the means to localise this field's label. So the failure of url is expected (though I'm surprised not to get an error), but the failure of urlfrom is not.

But many of Biblatex's own .lbx files seem to define not only urlfrom, but also url, so perhaps my interpretation of the revision history is mistaken. For example, dutch.lbx includes

tex/latex/biblatex/lbx/dutch.lbx:  url              = {{adres}{adres}},
tex/latex/biblatex/lbx/dutch.lbx:  urlfrom          = {{beschikbaar op}{beschikbaar op}},
tex/latex/biblatex/lbx/dutch.lbx:  urlseen          = {{bezocht op}{bezocht op}},

So this seems to be a bug, but I'm not entirely certain which species.

@moewew
Copy link
Collaborator

moewew commented May 24, 2024

At the moment url and urlfrom are indeed not (normally) used by the standard styles.

Unfortunately, the only trace of the history I could find is #71, which links back to a SourceForge page that no longer exists. But I think it is fair to assume the change to make url a localisation string caused backwards compatibility issues, so was rolled back. (Rolled back in the sense that the url field format does not use the bibstring. Not rolled back in the sense that the added url bibstring was also removed. It still exists, though I'm not sure if anyone uses it. Still at the time - and even now - removing it might have [had] consequences for existing documents, so we might as well keep it. Even if it confuses people who actually read the documentation very carefully a little...) Additionally urlfrom was added (possibly to support a format that was preferred in the Catalan localisation).

The url bibstring is indeed not used very often. I only found

\savefieldformat{url}%
\DeclareFieldFormat{url}{\bibstring{url}\addcolon\space\url{#1}}%

in the Marathi localisation module and https://github.com/josephwright/biblatex-ieee/blob/7f67eea42f55ee0c27c8358dd7cd64bf47ad4a4c/ieee.bbx#L52.

As far as ulrfrom goes: Some contributed styles use it, but of course they first need to do something like

\DeclareFieldFormat{url}{\bibstring{urlfrom}\addcolon\space\url{#1}}

(e.g. https://github.com/alex-ball/bathbib/blob/1ca4973eb0732d78709291fcca8123716cb172f2/biblatex/biblatex-bath.dtx#L5400, https://github.com/abntex/biblatex-abnt/blob/26ea8d415679e1b740815b6519181961697d81b9/latex/bbx/abnt.bbx#L1023).

@cfr42
Copy link
Author

cfr42 commented May 24, 2024

Ideally, I think the string used to label the field should be sensitive to localisation strings and user-modifiable without overwriting the formatter. But I don't know (obviously) what the complications are. So I understand there may be reasons not to do this. However, I think the setup could be made less confusing for people who do look at the documentation.

If it is intended the field format be insensitive to localisations in the standard styles, could the documentation be amended to make this clear? For example, in section 4.9.2.15 (Labels), url, urlfrom and urlseen are listed consecutively, with no indication that the standard styles ignore the first two. Of course, it doesn't say that they are used, either, and I eventually worked out url probably shouldn't have any effect from the change listing. but urlfrom having no effect either was rather confusing. Something like 'Not used by the standard styles' would have made things a lot clearer.

A similar comment in the .lbx files would be nice, but probably not a great idea all things considered.

Isn't it a bit odd that an .lbx makes standard styles sensitive to a localisation string which is otherwise ignored? Or is there some historical reason for this discrepancy?

@moewew
Copy link
Collaborator

moewew commented May 25, 2024

I don't think we can change any of the default field formats here without breaking backwards compatibility really badly (as #71 already suggests), so I think the next best thing I can offer is a short note along the lines you suggested for the two "unused" strings. See f494b02.

Just a note about the documentation with regard to the standard styles: If you want to know exactly how the standard styles behave it is usually better to look at the code directly rather than to look in the documentation. The documentation has to document all of biblatex features and does its best to roughly describe what the standard styles do in passing, but when it comes to the finer details, not all of it is necessarily described in there and not all theoretically possible/implemented features are ready to use in the standard styles. It would be a huge undertaking to document the behaviour of the standard styles in more detail and to document for all implemented features in which cases they may or may not interact with the standard styles.

@cfr42
Copy link
Author

cfr42 commented May 25, 2024

I don't think we can change any of the default field formats here without breaking backwards compatibility really badly (as #71 already suggests), so I think the next best thing I can offer is a short note along the lines you suggested for the two "unused" strings. See f494b02.

Sounds good to me. Thank you.

[I do wonder what happens if one needs multilingual support which includes Marthi, though. Presumably things behave differently in that case.]

Just a note about the documentation with regard to the standard styles: If you want to know exactly how the standard styles behave it is usually better to look at the code directly rather than to look in the documentation.

I understand it would be a huge task, especially given that the targets are not entirely static, but this does mean that, in order to understand how the standard styles work, I have to be able to understand the source code. That's a far from trivial requirement. The code is rather sparsely commented and split across multiple files which interact in ways which are not always at all obvious.

I should say that I greatly appreciate the effort which has gone into developing and maintaining Biblatex/Biber. It's really fantastic work and I don't want to sound ungrateful. I am extremely grateful. I'm aware that I don't know the reasoning behind some of the decisions made and that it is easy to think an element of software design is not sensible when I don't understand the reasons for it.

@moewew
Copy link
Collaborator

moewew commented May 26, 2024

[I do wonder what happens if one needs multilingual support which includes Marthi, though. Presumably things behave differently in that case.]

Well, technically the comment I added is not quite correct. As I said above, the string is used for Marathi (but only for entries in that language, even if you use multiple languages in your document).

@cfr42
Copy link
Author

cfr42 commented May 26, 2024

Ah, OK. That makes sense.

@moewew moewew added the fixedindev Fixed in current DEV version label Jun 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation fixedindev Fixed in current DEV version
Projects
None yet
Development

No branches or pull requests

2 participants