Ah and @brianteeman do you agree that we don't allow the values to be translated or do you want me to move them to language strings?

Correct they don't need to be translated. Not even sure they could be

Not sure if its my branch but I am now missing some strings. Can you check please

We don't need the PLG_SYSTEM_HTTPHEADERS_ADDITIONAL_HEADER_DESC anymore and all the strings for the options can go as well as things like X-XSS-Protection should not be translated.

Finally can you change the name to System HTTP Headers - we have a space bar on an english keybard :)

Correct they don't need to be translated. Not even sure they could be

Done also for the referrerpolicy rules.

Not sure if its my branch but I am now missing some strings. Can you check please

What do you mean? did you pull my branch?

We don't need the PLG_SYSTEM_HTTPHEADERS_ADDITIONAL_HEADER_DESC anymore and all the strings for the options can go as well as things like X-XSS-Protection should not be translated.

XSS Protection? I guess you mean the referrerpolicy?

Finally can you change the name to System HTTP Headers - we have a space bar on an english keybard :)

Done. :)

I fixed my branch and now this is all good - my concern with the language strings can be illustrated by this string
PLG_SYSTEM_HTTPHEADERS_REFERRERPOLICY="Referrer-Policy"

I am concerned that "Referrer-Policy" would be translated by the TT and it absolutely must not be. The same applies to all the other headers which must not be translated in the text.

From our experience with the "installation" folder string the TT will ignore any notes we add to the language file not to translate these words and the only solution we found for that one was to remove "installation" from the language file strings and just have a %s

Its not ideal but i cant think of any other way to prevent these strings from being translated

I am concerned that "Referrer-Policy" would be translated by the TT and it absolutely must not be. The same applies to all the other headers which must not be translated in the text.

Agree my point is that we use to include the link with more infos using that language string. Do you think we should drop them?

well its not just there it is also in the post installation message and some of the _DESC

other than the ugly %s i dont know what else to suggest

well its not just there it is also in the post installation message and some of the _DESC

hmm my problem is that i don't know how to append them using %s as the postinstall is hardcoded and the same apply to the xml labels and description.

maybe ask the TT Leader for some input?

maybe ask the TT Leader for some input?

@infograf768 can you please take a look here? Thanks!

I meant https://volunteers.joomla.org/joomlers/267-ilagnayeru-mig-manickam

Ping @imanickam too.

Good Morning!

Reviewed the xml files and I do agree that the values need not be derived from the language strings. Whereas, the description text for the options could use language strings (e.g. JYES, JNO).

Brian's concern is very valid that it should not happen just like the word 'installation' has been translated in the installation ini files. However, I feel that this case is slightly different.

We can have the policy names (e.g., Referrer-Policy, X-XSS-Protection) as distinct language strings with language constants identifying the policy name so that they are grouped in one place in the language file, and have a comment not to translate the policy names.

Example:
; Please DO NOT TRANSLATE the language values for the language strings starting with PLG_SYSTEM_HTTPHEADERS_POLICY_NAME
PLG_SYSTEM_HTTPHEADERS_POLICY_NAME_REFERRERPOLICY="Referrer-Policy"
PLG_SYSTEM_HTTPHEADERS_POLICY_NAME_XXSSPROTECTION="X-XSS-Protection"

As these language strings would be used for display purpose only, IMHO, it should not affect any outcome.

As for as using placeholders within the language strings of Post Install messages, let me request JM to offer suggestions.

Trying to find a solution.

In the mean while, please change EOL from Windows to Unix for the en-GB.plg_system_httpheaders.ini file

Also, when debug lang is on, I get these JGLOBAL strings constants for the tabs :

These JGLOBAL strings can replace the

COM_PLUGINS_HSTS_FIELDSET_LABEL="Strict-Transport-Security (HSTS)"
COM_PLUGINS_CSP_FIELDSET_LABEL="Content-Security-Policy (CSP)"

so that we get the same result when debug lang is on or not.

Some thoughts as they come:

This is a totally new plugin for a new version of Joomla where we will ask TTs to re-apply as TTs and where the packs will be quite different as 90% of the ini files will have to be largely modified.

Therefore the issue can't be compared with the installation issue which was a > 10 years old one. What I mean is that the "new" TTs will be strongly briefed about what should and what should not be translated in these new strings.

NOTE:
For forms (not for postinstall), this shows we could improve the field translations.
What I am thinking of is something like this:
add new $element(s) (or many, incremented) var-label="MYSTRING_VAR_LABEL" and var-description="MYSTRING_VAR_DESC"
Add these new strings in the ini file concerned. Group them.
Then, when present in the field, translate them with a JText_::_
Then, still if present in the field, instead of using a JText::_ for the label or description, use a JText::sprintf adding this new variable (or multi).
Looks like we could do that in FormField

This is a totally new plugin for a new version of Joomla where we will ask TTs to re-apply as TTs and where the packs will be quite different as 90% of the ini files will have to be largely modified.

I was not aware of that so maybe we can manage with just the "do not translate this" comment

It would have to be more precise depending on the strings as the words not to translate may be part of stuff which need translating.
Presenting these words not to translate between quotes helps Translators to understand that they do not need to be translated.

Example:
original string
PLG_SYSTEM_HTTPHEADERS_XCONTENTTYPEOPTIONS="<a href='https://scotthelme.co.uk/hardening-your-http-response-headers/#x-content-type-options' target='_blank'>X-Content-Type-Options</a>"
could be
PLG_SYSTEM_HTTPHEADERS_XCONTENTTYPEOPTIONS="<a href='https://scotthelme.co.uk/hardening-your-http-response-headers/#x-content-type-options' target='_blank'>\"X-Content-Type-Options\"</a>"

In a sentence then yes it does but where it is the entire label as it is here then it is not correct for the UI

Thanks i have just commited the "do not translate" comments & used the JGLOBAL strings as suggested please review. 38abbbd

@zero-24 its not that simple

"HTTP Header" can not be translated - nor can ANY of the technical terms anywhere

"HTTP Header" can not be translated - nor can ANY of the technical terms anywhere

I have just extended the comments. :)

Done thanks @brianteeman

Is Maximum recording time same as Maximum registration time ?
if it is let's choose one of them only

@brianteeman
Why maximum recording time should not be translated?

Sorry I might be confusing the maximum recording time - I thought that was the name of the actual attribute. Looking further if i understand the code correctly this refers to the attribute "max-age". That attribute should not be translated AND "maximum recording time" is not a correct description of "max-age"

the attribute "max-age" refers to how long the policy should remain in effect https://tools.ietf.org/html/rfc6797#section-6.1.1 so I am not sure why you have written it as "maximum recording time"

it should just be the untranslatable "max-age"

pushed thanks!

I have tested this item ✅ successfully on 0aecc2f

I know this is beyond the scope of this PR, how about making Site, Administrator, Both a dropdown instead radio buttons?

@zero-24
If this #20525 is merged, we could simplify your strings by grouping the values not to translate in simple strings and then using a placeholder where fit.

Even better. Let's take this label
PLG_SYSTEM_HTTPHEADERS_HSTS_MAXAGE="max-age"

we can simply do
PLG_SYSTEM_HTTPHEADERS_HSTS_MAXAGE="%s"
and add in the field xml
varLabel="max-age"
and TTs will never mistake.

That only helps where the term is the only thing in the string

That only helps where the term is the only thing in the string

Indeed. It is a bonus. But the feature let's use the variable from another string as everybody understood... Example:

PLG_SYSTEM_HTTPHEADERS_CONTENTSECURITYPOLICY="<a href='https://scotthelme.co.uk/content-security-policy-an-introduction' target='_blank'>Content Security Policy (CSP)</a>"
can be replaced by
PLG_SYSTEM_HTTPHEADERS_CONTENTSECURITYPOLICY="<a href='https://scotthelme.co.uk/content-security-policy-an-introduction' target='_blank'>%s</a>"

and then we use in the field

				<field
					name="contentsecuritypolicy"
					type="radio"
					label="PLG_SYSTEM_HTTPHEADERS_CONTENTSECURITYPOLICY"
					description="PLG_SYSTEM_HTTPHEADERS_CONTENTSECURITYPOLICY_DESC"
					class="switcher"
					default="0"
					varLabel="JGLOBAL_FIELDSET_CSP"
					>
					<option value="0">JDISABLED</option>
					<option value="1">JENABLED</option>
				</field>

Where JGLOBAL_FIELDSET_CSP (already present string) has the value "Content-Security-Policy (CSP)"

Same evidently for the description and other strings in the ini files, and not only for this plugin.

Until that PR is merged i think we should not block this PR and get some tests + merge? What do you think?

As merging #20525 would imply many changes in the ini strings, not sure we should.
If both people here in favor or immediate merging were just testing 20525, we could get further pretty fast. It is not as we would be in such a hurry that this PR here has to get in at once because of a urgent release.

I guess this will need updating when #20525 is merged (it is RTC)

Please remove

JGLOBAL_FIELDSET_HSTS="Strict-Transport-Security (HSTS)"
JGLOBAL_FIELDSET_CSP="Content-Security-Policy (CSP)"

from the language files and just hardcode them in the XML - if they are standalone strings like this that should not be translated them don't put them in language files.

Thanks implemented now @wilsonge ?

CSP is not to be translated - source
https://developer.mozilla.org/fr/docs/Web/HTTP/CSP

CSP is not to be translated - source
https://developer.mozilla.org/fr/docs/Web/HTTP/CSP

@brianteeman I have just looked at the current strings. ATM we only have one line with CSP
https://github.com/joomla/joomla-cms/blob/4.0-dev/administrator/language/en-GB/en-GB.plg_system_httpheaders.ini#L15
=> The complete string is marked as not to be translated.

The others are Hardcoded now in the XML like George suggested. I'm still missing something?

@wilsonge
It is pretty frustrating that #20525 has been RTC for a while and not merged, which would have simplified this PR here and be quite useful in future other cases.
It would really help volunteers if a decision had been taken about it and not just ignoring it.

When #20525 is merged we can do a PR that implements that.

This has been merged so we can move forward with the csp integration.