Fix issues with metadata api view redirect

[tylerjmchugh]

There are a couple of issues with the metadata API view redirect introduced in #8966.

1. Language not preserved

The redirect URL does not include the language, so the link always resolves to the default language.

This means multilingual emails would have multiple links pointing to the same page with the default language. It would be better to have each link point to its respective language.

This PR adds support for a language parameter and uses it in the redirect URL. If the language code is invalid, it falls back to the default language.

2. Formatter name in permalink

The formatter name is currently embedded in the permalink. This creates a fragile link — if the formatter is renamed or removed, existing links will break.

This PR removes the formatter name requirement from the URL by implementing a configuration-based lookup with backwards compatibility. When the recordViewFormatter parameter is not provided in HTML requests, the API now retrieves the default formatter from the UI configuration instead of failing or using a hardcoded default.

This PR contains API changes

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[jodygarnett]

I am confused if not providing recordViewFormatter breaks the initial intent of the metadata api view allowing search engines and so on to have simple content to index.

#8949 indicates this api endpoint was intended for browsers with limited capabilities; I always thought it was for search engines to crawl?

We should get some clarity before merging this PR.

[jodygarnett]

Please clarify use of metadata api endpoint. I am under the impression that redirect by default would break the ability of this to be used by search engine indexing (which requires simple html content).

[ianwallen]

@jodygarnett, I'm not aware of the use by search engine? For search engines to index the permalinks, would they not need a page to crawl that would have all these links otherwise where would it be getting all the permalinks? I'm not aware of any endpoint that returns all the permalinks for a web crawler - but maybe it exists? Hopefully we don't need to manually submit each permalink to an index server :)

I do believe that the default formatter may be used by PDF generator? And the software should be defaulting to the basic formatter when printing to PDF or that would be a bug.

The concept was already approved in the past with PR #8966. This PR is addressing some issues that was introduced in that PR.

The old logic was still working however if the default view was changed. i.e. Changed to use default view.

Then permalink looked like this

/geonetwork/srv/api/records/7ae323f7-c15a-4d06-b3f2-26ea43ea44a3?language=all&recordViewFormatter=defaultView

And this is incorrect as recordViewFormatter should be determined by the configuration and not hardcoded. This will allow someone to change the default formatter and all existing permalinks should start using the new configuration.

The generated permalink should instead look like this no matter what formatter was used as the default.

/geonetwork/srv/api/records/7ae323f7-c15a-4d06-b3f2-26ea43ea44a3?language=all

For the other issue related to language, this is mostly related to emails containing the permalink did not include the language so the links were not correct.

[fxprunayre]

For search engines to index the permalinks, would they not need a page to crawl that would have all these links otherwise where would it be getting all the permalinks?

See https://docs.geonetwork-opensource.org/latest/tutorials/introduction/extra/ "Search Engine".
Also #8939 improve JSON-LD formatter and doc about SEO.

[jodygarnett]

Thanks @fxprunayre that documentation has /srv/api/sitemap linking to html:

GeoNetwork includes on any html representation of a metadata record a representation of that record in schema.org encoded as json-ld. This enables the search engine to extract the information in a structured way.

Does that confirm that the html files are intended for the search engines. I am just trying to determine if the links from /srv/api/sitemap are going to work correctly after these changes.