Add en.json generator

[yukienomiya]

Changes:

1. Add the getenJSON.js script that extracts the data from the data.json file and automatically generates another JSON file (en.json) containing all the English strings that have to be translated.
2. Add the en.json file.
   This file could serve both as a template for new translations and as an always up-to-date model to compare the translations with, in order to know when and where they need to be updated.
   • The structure of the en.json is slightly different from the one currently in use (see below), so the other files would have to be modified as well.
   • The en.json file is about x4 times larger than the Spanish version. This is because it contains all the p5.js classes and their related fields/methods.
3. Add the enJSONStaticStrings.json file that contains static text from the Reference section. These entries are then added at the beginning of the en.json file.
4. Update the index.hbs file: add the script section that swaps text from class pages of the Reference (it currently only performs the swaps in method/fields pages).

Structure of the en.json file:

Structure changes:

• Description elements: from strings to arrays of strings.
  In the original documentation, the description text is split into paragraphs. This is especially important in long descriptions -Classes' for instance- because it helps with the text's legibility.
  In the translated JSONs the descriptions were saved as single strings and therefore displayed on the website as single paragraphs.
  To fix this, I saved the descriptions as arrays of strings, where each array element represents a paragraph.
• Parameter elements saved by their name.
  The parameter elements are currently saved in arrays of strings, where each element has a "paramType: paramDescription" structure. They are then inserted in the translated webpage in the order in which they were saved. This is problematic because every little edit on the webpage could mess this order up (here for example, the descriptions of the "colorstring" param and the "a" param are switched).
  To fix this, I saved the "params" elements as object, where each element has a "paramName": "paramType: paramDescription" structure.

[limzykenneth]

Can the two JSON files be combined into one? Just to make the process of copying it to create a new language more straightforward.

[yukienomiya]

@limzykenneth I think I explained the enJSONStaticStrings.json file poorly.

I split the en.json into three main sections:

1. static strings: static text from the Reference section of the website (i.e., the placeholder in the Search bar or the "Parameters" string in methods pages)
2. module names: for the group and subgroup titles in the Reference's main page
3. documentation

While the module names and the documentation are extracted from the data.json, the static strings can't be, so I stored them in the enJSONStaticStrings.json to have a place to fetch them when the getenJSON script builds the en.json.
(I guess it would make more sense to save them in the YAML file, but I don't know if that's okay..?)

So, in short, the enJSONStaticStrings.json is only needed for building the en.json, which is the only file that will have to be copied when starting a new translation.

[limzykenneth]

I see, in that case can the data in enJSONStaticStrings.json be included directly in the code of getenJSON.js?

If I understand correctly the workflow is generate en.json by taking data from data.json and static entries and combine them into en.json; to create a new translation it still is copying en.json and start from there; to update a translation, one would check the latest generated en.json and update the respective language's JSON file. If that is the case and there being not too many entries in enJSONStaticStrings.json nor would it change often, not having it as a seperate file could reduce confusion about what role it plays in the translation process.

[yukienomiya]

I originally included the strings in the getenJSON.js script, but changed it after discussing it with Evelyn. We both agreed it would be cleaner this way. I didn't consider the fact that it could be confusing, to be honest. @outofambit what do you think?

[limzykenneth]

I guess one of the main reason I find it potentially confusing is because of the name enJSONStaticStrings.json which almost implies there should be esJSONStaticStrings.json, zh-HansJSONStaticStrings.json etc.

[yukienomiya]

I see, maybe just staticStrings.json then? I'm not great at coming up with file names 🙈

[limzykenneth]

staticStrings.json would be better in this case.

[lmccart]

@yukienomiya this is looking great! It seems like there are a few details in your description and the conversation here that are not yet captured in the i18n_contribution.md file yet. I wonder if the "How the website works" section could be updated a bit to include this? Or if this feels too in-depth for this particular section, maybe just a "Notes" section at the end of this page could be useful?

[yukienomiya]

I'm closing this PR because I'm splitting it into two new ones, in order to separate the JSON structure change from the getenJSON script.
@lmccart, thank you 😃 I'll make sure to update the i18n_contribution.md file in the new ones!