Remove <front> from t()

I am not sure what the context is, but I don't think <front> should probably be translated at all? It is probably something that needs to be typed in literally by an administrator to indicate the front page of the site, and it should not be translated into another language?

What is the context for the string usage in the GDPR module?

I think this might even have been filed under the wrong project too? https://localize.drupal.org/translate/projects/gdpr says German has been fully translated anyway. One of the instances of <front> that's been linked to in the issue summary here is from the https://www.drupal.org/project/eu_cookie_compliance project, so I'll move this ticket over there. It looks to me as though the string has been picked up because it is the initial config value in eu_cookie_compliance.settings under the key 'popup_link', which is defined as type: label in that configuration's schema definition. The label type makes the value translatable.

So I'm not sure why this would be an issue. I would guess that it's entirely correct for different languages to use a different path for this link, but initially all languages default to using the home page - so I imagine it's correct for this string to be left unchanged in German/etc?

This is basically the same as the core issue about the frontpage: #2275865: Per language settings (vs translated settings) are not directly supported. Drupal core does not have a way to say that a config key is localizable, but not translatable text, meaning it should not be extracted with potx.

So considering that core does not support that, the correct thing for now would be to make that type: path, like the frontpage. But it might break existing sites that did localize this configuration setting.

We've had this report before, and concluded we couldn't remove it from translations, since users do want to translate the string once it's set. Would it be better if we used /node as the default value?

I suspect the issue of an untranslated translatable string is better than shifting the burden to end users having to remember to change that setting if their homepage is not /node?

So I'd tentatively suggest closing this as 'Closed (won't fix)', as action is ultimately restricted by a limitation in Drupal core, as Berdir explained. As far as I can see, the 'bug' is just that a % on a dashboard of translated strings isn't 100, rather than an 'actual' issue that can affect end users?

Sorry if that doesn't recognise something about the nature of the issue!