Clarify in documentation that \zcref requires \zlabel (rather than \label)

[jspitz]

This package looks very promising, thanks for setting this up. However I fail to succeed with even the most simple example. Maybe this is just a problem on my part (or a documentation issue). Consider:

\documentclass[10pt,a4paper]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

\usepackage{zref-clever}

\begin{document}
    Look at \zcref{label}.

    \section{\label{label}Heading}

    Bla bla bla.
\end{document}

This yields:

LaTeX Warning: Reference `label' on page 1 undefined on input line 8.

The aux file has:

\relax 
\providecommand\zref@newlabel[2]{}
\newlabel{label}{{1}{1}}
\@writefile{toc}{\contentsline {section}{\numberline {1}Heading}{1}{}\protected@file@percent }
\gdef \@abspage@last{1}

[jspitz]

Also note that

    Look at \ref{label} and \zcref{label}.

output the correct reference for \ref but ?? (and the warning) for \zcref

[jspitz]

Oh, I understand, it requires \zlabel rather than \label. This didn't occur to me from the documentation, so maybe this is a documentation issue after all.

[gusbrs]

Hi @jspitz , thank you for your interest in the package and for your feedback.

Yes, indeed, zref is an independent reference system altogether, it has its own reference commands (which zref-clever extends), and its own \zlabel as you found out. I did presume zref is not that well known, I guess I thought the "How-tos" section would be enough for this. And I do mention \zlabel in the user interface section. But I think you are right it deserves some more prominence there. I'll arrange to that soon. Thank you.

Note that there are some exceptions, in a few places where \label has some kind of special support, or where the label must be set indirectly from a label argument. See "Limitations" and "Compatibility modules" sections. Notably, for amsmath environments, \label must be used.

And, if I may, since you are a Linguist and a native speaker of German, I'd very much appreciate feedback on the declension support (both noun declension and the nudge feature). Particularly in regard to the user interface, if it feels "natural" or "clumsy". I have learned German myself "als Fremdsprache" and so my way to the language was very much mediated by a number of "declension cases tables/cheat-sheets". But one thing I was concerned about was whether native speakers of German themselves (currently the only language with noun declension support) keep the declension cases on a conscious level or "just know", without thinking about it too much.

[jspitz]

As to declension, I am not sure users are always equipped with enough metalinguistic knowlegde to clearly determine the current case (as in: "this is dative"). But I do not have a really good alternative. In general, the UI looks reasonable to me (I have not tried it extensively though).

There are some localizations where I would decide differently. Particularly the -es genitive suffixes, though certainly correct, are rather antiquated and marked nowadays (I'd rather say "des Buchs" than "des Buches" and "des Teils" than "des Teiles", for instance). But this is stylistic variation and thus certainly differs intersubjectively.

In the long term, you will also need to differ language varieties. For instance, in Swiss German, footnote is to be localized as "Fussnote" rather than "Fußnote" (as the <ß> is not common in Switzerland). I have no concrete example for pre-1996 vs. post-1996 (babel's "n") spelling, but at least in theory, this might get relevant as well. I'd suggest, as in babel and polyglossia, to define a hypervariety (identical with ngerman) which is inherited and can be overwritten by the varieties.

[gusbrs]

As to declension, I am not sure users are always equipped with enough metalinguistic knowlegde to clearly determine the current case (as in: "this is dative"). But I do not have a really good alternative. In general, the UI looks reasonable to me (I have not tried it extensively though).

That was pretty much my assessment too: "may feel not very natural to make the case explicit, but I don't see a better way to do it". There are some attempts to automate surrounding material too (https://github.com/frougon/xcref, https://github.com/Jinwen-XU/crefthe) and, though I find them very interesting and cool, I did fear to venture in those waters. At least I couldn't figure out an infrastructure and UI which would be general enough across languages. The current state of things was the best I could come up with. Let's see how it goes. And if you do have further thoughts later on, please don't hesitate to share.

There are some localizations where I would decide differently. Particularly the -es genitive suffixes, though certainly correct, are rather antiquated and marked nowadays (I'd rather say "des Buchs" than "des Buches" and "des Teils" than "des Teiles", for instance). But this is stylistic variation and thus certainly differs intersubjectively.

Please, feel very welcome to open an issue about these. My German is quite limited and, even if it was not, the dictionaries should correspond to usage by native speakers. In particular, I did have a lot of doubt about the -es genitive suffixes and, in a number of cases had to use Google Ngram Viewer to have some criterion, for I had myself no idea.

In the long term, you will also need to differ language varieties. For instance, in Swiss German, footnote is to be localized as "Fussnote" rather than "Fußnote" (as the <ß> is not common in Switzerland). I have no concrete example for pre-1996 vs. post-1996 (babel's "n") spelling, but at least in theory, this might get relevant as well. I'd suggest, as in babel and polyglossia, to define a hypervariety (identical with ngerman) which is inherited and can be overwritten by the varieties.

I do expect that, but I must rely on interested people coming forward and contributing the necessary changes. Currently the package has no mechanism for inheriting a language and then making just a number of changes, each dictionary is actually independent. I have thought about this, but I was unsure whether the demand for language varieties would be enough to compensate the extra complexity. The price to pay, of course, is redundancy in the dictionaries. I'll add to my list of todos to think this over again in this light.

Thank you very much for thoughts about this!