Make tech table messages of security.txt test editable and translate them in Dutch

[baknu]

1. Put tech table messages for security.txt in content repo and make them editable
2. Translate these messages in Dutch

Note that 1 is also nice for other instances of the Internet.nl code base, like the BR and DK version.

[mxsasha]

Mostly documenting my own research: this is not well supported by our code at all. In short, these strings all have parameters (e.g. "{name} field must appear at least once." or "Retrieved security.txt from {found_host}"). We do not have support for parameterised translations in the tech table.

The translation of tech table content happens here:

Internet.nl/interface/templatetags/translate.py

Lines 108 to 123 in c9ecd9a

	elif value in [
	"detail tech data yes",
	"detail tech data no",
	"detail tech data good",
	"detail tech data secure",
	"detail tech data insecure",
	"detail tech data bogus",
	"detail tech data not-applicable",
	"detail tech data not-tested",
	"detail tech data not-testable",
	"detail tech data not-reachable",
	"detail tech data phase-out",
	"detail tech data sufficient",
	"detail tech data insufficient",
	]:
	value = _(value)

Called from here:

Internet.nl/interface/templates/details-test-item.html

Line 25 in c9ecd9a

{% render_details_table testitem.tech_string testitem.tech_data %}

In turn from here:

Internet.nl/interface/templates/domain-results.html

Line 81 in c9ecd9a

{% include "details-test-item.html" with testitem=details.http_securitytxt %}

The information available in the context for each test is the return from this method:

Internet.nl/checks/categories.py

Lines 104 to 118 in c9ecd9a

	def fill_report(self):
	"""
	Return the final state for this subtest.
	"""
	return {
	"label": self.label,
	"status": self.status,
	"worst_status": self.worst_status,
	"verdict": self.verdict,
	"exp": self.explanation,
	"tech_type": self.tech_type,
	"tech_string": self.tech_string,
	"tech_data": self.tech_data,
	}

The tech_data is currently a list of messages. If we put codes / translation keys in here, that will be insufficient, because we don't have enough info to produce a useful message (like line number or name of field that is missing).

The origin in the database of all the data is the report ListField which, despite its name, usually contains dict.

Internet.nl/checks/models.py

Line 682 in c9ecd9a

report = ListField(default="")

Likely best option: add a new tech_type where rather than a list of strings, each message has a context dict too. The context is then used as parameters for the translations, resulting in a single list of translated messages to render. Pretty clean, works in different languages, extendable. Probably will result in an API change as tech_data is rendered there, but I'd argue this is a more useful output format in the API than human-readable strings.