Following up on the mailing list as this tasks lacks a bit in its specification. Correct me if I am wrong: I do not think that "structured" means structured in the way a developer natively understands; the more important word is "overview" in the ticket description. In my opinion, there is no particular use in having all texts, for example, in some spread sheet or data base. I guess it would just be nice to have a document (i.e. PDF) where every rendered HTML snippet of the "templates" folder is a single page headlined with the file name (basically, allowing the questionnaire to be created offline). The raw content of the .js files in "app/nls" could just be added to such a document without any parsing.

We've discussed this task nearly half an hour during Sprint Planning last week but it seems the purpose is still unclear (which might partly be also my fault 'cause I have not explained it right here on the ticket). So, let me do this now:

The goal of this task is to have a list (e.g. in a PDF, Spreadsheet, etc..) of all string messages that can be shown to the user by the tool. The purpose of this is NOT technical but to allow the product manager (Katja from BWK) to have an overview of these messages in order to plan future changes to the tool.
My first idea how to solve this was creating a screenshot of every possible (or at least the most important) "state" the website is shown to the user. Another solution would be to just extract all human readable message strings from the code and put them into a list (plus some context when they are shown).
The tool isn't really complex and the number of messages isn't high. IMHO browsing through the code and extracting the texts could be done in roughly one hour. It's also not something we are going to do again in the future, so creating a tool that does this automatically might be a bit overkill, but in the end this is up to the assignee of the task.

However, I agree this is not a very satisfying task though.

First I thought strings would be inline in the app js files, so I wrote
a one-off script which extracts all the strings and writes them to an
HTML file, together with hyperlinks to the file+linenumber on github,
and an editable text field for explanations or notes. A human would
then go through all the string entries and remove those that aren't
shown to the user (this part cannot be easily automated).
Then I noticed that the app is already using the NLS thing, so all the
user-visible strings should be in files in app/nls. So my first script
would be useless. So I wrote another one-off script... Which extracts
the strings and their identifiers, and searches the js code for places
which reference the identifiers. So this generates a text file which
looks like this:

./AjaxError.js:
'contentpage-missing' => 'Could not retrieve the requested page. Please try accessing the page again.'

../Navigation.js 124 var error = new AjaxError( 'contentpage-missing', ajaxOptions );

'page-invalid' => 'The input could not be resolved–it appears to be invalid.'

../Api.js 411 errorCode = 'page-invalid';

'page-missing' => 'Could not locate the requested resource.'

../Api.js 409 errorCode = 'page-missing';

'questionnaire-page-missing' => 'Content is missing, the questionnaire could not be loaded completely.'

../Questionnaire.js 353 deferred.reject( new AjaxError( 'questionnaire-page-missing', ajaxOptions ) );

All of this still makes little sense to me, but I guess that is what's wanted, right?

@jkroll can you run the scrip again and include also the HTML files. The list of strings in https://github.com/wmde/Lizenzverweisgenerator/blob/master/strings/nlsref.html seems to only cover strings inside the JS files. E.g. the text from https://github.com/wmde/Lizenzverweisgenerator/blob/master/templates/content/de/frontpage-help.html does not show up in that list.

@jkroll I took care of it and it's done now, I will close the task.

What is the reason for the extracted strings being uploaded to the application repository? If, at least, the script itself was included... Looking at the repository now, that string compilation seems quite out of place.