None of the JHELP strings should be translated as otherwise we would get 404s . afaik this has been instructed to all Translation Teams.

https://docs.joomla.org/J3.x:Making_a_Language_Pack_for_Joomla#What_not_to_translate

@infograf768 so they can acutally be removed from any non-en-GB package? As they would fallback to the en-GB version than right?

Well in Crowdin nobody reads this and everybody can translate.
I thought it is possible to mark strings for 'not to translate' in Crowdin. Or remove them from the translation-files into another (they don't belong there!).

maybe @Bakual knows whehter that is possible for crowdin files?

I changed What not to translate to try to make it clear that this applies to all strings starting JHELP_ and not just JHELP_COMPONENTS_. Also in the test French Language pack the strings are in fr-FR.ini rather than joomla.ini (confusing) and the content does need to be copied over. Putting these strings in a separate ini does seem like a good idea! For 4.1?

Also in the test French Language pack the strings are in fr-FR.ini rather than joomla.ini (confusing)

This is a 3.x vs 4.x change ;)

Putting these strings in a separate ini does seem like a good idea! For 4.1?

Maybe that or somehow that strings can be marked as not to translate in crowdin.

Different question could be why does that need to be a language string an can not be done as JSON file?

so they can acutally be removed from any non-en-GB package? As they would fallback to the en-GB version than right?

Crowdin, as well as com_localise, don't differentiate between JHELP_ strings and other strings. As all strings are present in the reference language which is en-GB, they are also presented for the other languages.

The main difference between crowdin and other tools is that anyone can propose a translation in crowdin, including people who have no idea what they are doing. And this not only for the JHELP_ strings... This forces the language coordinators to spend a lot of time correcting/ignoring such proposals.

Indeed the best would be to separate totally these strings from the language packs and devise a way to load them separately OR not use constants but values in the key code

<layout title="COM_CONTENT_ARCHIVE_VIEW_DEFAULT_TITLE" option="COM_CONTENT_ARCHIVE_VIEW_DEFAULT_OPTION">
		<help
			key = "JHELP_MENUS_MENU_ITEM_ARTICLE_ARCHIVED" // change to "Menus_Menu_Item_Article_Archived"
		/>

I suppose code concerned is
$ref = $attributes['help'];
$keyref = \JText::_($ref);

Also in the test French Language pack the strings are in fr-FR.ini rather than joomla.ini (confusing)

Yeah, com_localise version for J4 (in development) automatically corrects the j3 files to j4 format. Both format continue working in j4 but evidently can't be compared thus why I correct the format.

If they should not be translated ever then there is zero point in them being in the language files and there is zero point in joomla code using JHELP_MENUS_MENU_ITEM_ARTICLE_ARCHIVED and the code should use the correct Menus_Menu_Item_Article_Archived

It is architecturally wrong to use the language translation system to change the format of a string

I see that JHELP_MENUS_MENU_ITEM_ARTICLE_ARCHIVED is used in the front end in com_content/tmpl/archive/default.xml (and many others too). But I have no idea how/where that xml file gets used or where the Help button might appear. Can anyone enlighten me?

I can think of one potential reason for keeping the JHELP keys as translatable strings: someone might come along with a better form of Help and perhaps use a plugin plus overrides to select - just brainstorming.

I guess it was done this way originally to let have custom help sites for custom distribs. Therefore including 3rd party extensions.

Changing the complete keys is easy as @infograf768 has shown

changing the compound keys is going to be harder

		// Compute the ref_key if it does exist in the component
		if (!$lang->hasKey($ref_key = strtoupper($component . ($section ? "_$section" : '')) . '_CATEGORIES_HELP_KEY'))
		{
			$ref_key = 'JHELP_COMPONENTS_' . strtoupper(substr($component, 4) . ($section ? "_$section" : '')) . '_CATEGORIES';
		}

I had a look at Crowdin and noticed that the string markers include hidden (visible only for project managers and proofreaders) - can we use that? I also noticed that US-English has 13 untranslated JHELP_ strings.

Can we put JHELP_ strings in a separate file and include it right after joomla.ini in Libraries/src/Language/Language.php on line 712. That is the only place I can find joomla.ini mentioned.

In Crowdin we can indeed hide strings. We can also add contextual informations.

In Crowdin we can indeed hide strings. We can also add contextual informations.

Then this is a non-issue

It would be good to get a second test of https://issues.joomla.org/tracker/joomla-cms/30712 so that we can get the new strings (help file names that appear as page titles in English) into the source joomla.ini file. It only takes a few minutes to confirm a couple of Help pages are working as expected.

In Crowdin we can indeed hide strings. We can also add contextual informations.

@Bakual is the method to do this something that has to be done on crowdin or is it something we set here in code.

In Crowdin.
Context could in theory also be done here, but it's simpler in Crowdin.

So can this be done please and then this can be closed

I'm away from my computer. I try to remember when I'm back from holidays.

what is this holidays you speak of. i do not know the meaning of that word ;)

The joy of being a simple employee ?

I've hidden around 630 strings in Crowdin starting with "JHELP_" (staging and 4.0-dev). I guess I found at least most of them.

@MartijnMaandag Do you think there is anything left to be done? Otherwise this issue could be closed.

Thank you! I do think this is it.
Do you know what happens if someone already translated this (the wrong way). Will the transalation be ignored?

Do you know what happens if someone already translated this (the wrong way). Will the transalation be ignored?

Since you can still translate hidden strings as proofreader and manager, I'd expect if a string has already been wrongly translated, it stays translated.