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

relatedtype: translationas or translatedas? #1359

Open
pcdi opened this issue May 24, 2024 · 1 comment
Open

relatedtype: translationas or translatedas? #1359

pcdi opened this issue May 24, 2024 · 1 comment
Labels
documentation fixedindev Fixed in current DEV version

Comments

@pcdi
Copy link

pcdi commented May 24, 2024

Perhaps this is merely a documentation issue, but it appears that since 8950959#diff-7a310f17be14555280c15848ec66a41079361c6e091089e54918f0b87dd68360R2586, relatedtype = {translationas} has been called relatedtype = {translatedas} in the documentation in two locations even before the proper documentation for translationas was introduced in 50062d846d308c75757ed5be27f4f9e30d996563:

@Book{key3,
...
related = {key2},
relatedtype = {translatedas},
...
}

The related entry feature is enabled by default by the package option \opt{related} from \secref{use:opt:pre:gen}. The related information entry data from the related entries is included via a \cmd{usebibmacro\{related\}} call. Standard styles call this macro towards the end of each driver. Style authors should ensure the existence of (or take note of existing) localization strings which are useful as values for the \bibfield{relatedtype} field, such as \texttt{translationof} or perhaps \texttt{translatedas}. They can then define macros and/or formats with the name \texttt{related:\prm{relatedtype}} which will be used to format the data. The package \path{biblatex.def} contains macros and formats for some common relation types which can be used as templates. In particular, the \cmd{entrydata*} command is essential in such macros in order to make the data of the related entries available. Examples of entries using this feature can be found in the \sty{biblatex} distribution examples file \path{biblatex-examples.bib}. There are some specific formatting macros for this feature which control delimiters and separators in related entry information, see \secref{aut:fmt:fmt}.

These are still present today:

https://github.com/plk/biblatex/blob/ac2456c2492861451547659702ae4a72264e4997/doc/latex/biblatex/biblatex.tex#L3460-L3465

https://github.com/plk/biblatex/blob/ac2456c2492861451547659702ae4a72264e4997/doc/latex/biblatex/biblatex.tex#L8112

Using translatedas compiles without error (presumably as intended). I am now wondering if this is only something that needs to be fixed in the documentation or if translationas was indeed called translatedas before and there are other places where corrections need to be made.

moewew added a commit to moewew/biblatex that referenced this issue May 24, 2024
@moewew
Copy link
Collaborator

moewew commented May 24, 2024

Thanks for catching that. I pushed cd38ac9 to change the docs to refer only to translationas. I guess translationas sounds more clunky (at least it does to me, but then I'm not a native English speaker) than translatedas, case in point:

translationas = {{translated as}{trans\adddotspace as}},

But since we have all the setup for translationas we should probably stick with that.

You can use arbitrarily named relatedtypes, but if you use a type for which there exists a bibstring you get localised output etc. So there is no issue with translatedas working (or not working) as it does at the moment. But we should probably only advertise translationas in the docs.

@moewew moewew added documentation fixedindev Fixed in current DEV version labels May 24, 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