Warning: Automatically setting /Lang (en) or /Lang (en-US) without \DocumentMetadata{} would be a bad idea

[Deleted user]

Severity: a warning, not a bug yet.

In the Abstract of “The LaTeX PDF management testphase bundle” version 0.95x, it's unclear whether after the test phase of the pdfmanagement, the command \DocumentMetadata{} (without any contents) is needed to activate the PDF management, or whether the PDF management is activated even without \DocumentMetadata{}.

In the second case, it would be a bad idea to force /Lang (en) or /Lang (en-US) into the Catalogs of the PDF files obtained by simply re-compiling old, unchanged LaTeX documents. This would make the PDF files produced from all non–US-English LaTeX documents worse. As of now, compiling

\documentclass{article}%or \documentclass[ngerman]{article}
\pdfcompresslevel=0
% you may add \usepackage[ngerman]{babel} here
\begin{document}
Bratpfanne% German contents
\end{document}

does NOT put /Lang (en) or /Lang (en-US) into the output PDF, regardless of whether the author specifies the language ngerman as a class option or via babel or not at all. This (not specifying the English language in the Catalog) is jolly good and should stay this way. Of course, if the language option ngerman is specified in as the main language in a clear way in the input LaTeX document, we may opt for specifying /Lang (de) or /Lang (de-DE) in the Catalog, and it would probably be a wise thing to do (cf. http://github.com/latex3/babel/issues/244). However, we should NOT generate /Lang (en) or /Lang (en-US) automatically for such old, pre-pdfmanagement documents, since the resulting PDF file would be worse (because it'd specify a language inconsistent with the contents) than before the advent of the pdfmanagement code.

[Ulrike Fischer]

I doubt that we will activate the pdfmanagement if \DocumentMetadata is not used. In any case: the code that sets the /Lang entry is not in the pdfmanagement code, but in the \DocumentMetadata implementation.