Add versions of the consent forms and other docs

[yarikoptic]

regardless or in addition to proper i18n support (now we have i18n teams btw) we need to start versioning the form(s) which would help to also track which translation needs additional changes from previous one.

Two major choices:

use this repo version as a base

<this repo version>.[ult|gdpr|dpi|dua][.<patch>][.language[.LANGUAGEPATCH]]

pros

• simple to "implement"
• aligned with the releases of this repo so it would be easy to see differences between two specific versions .

cons

• jump in big progressions whenever even trivial changes introduced

use separate versions per each document

Use https://semver.org/ at large in a form MAJOR.MINOR[.language[.LANGUAGEPATCH]], with simple logic of

• MINOR goes up upon trivial changes -- typo fixes, reformatting etc.
• MAJOR going up whenever anything added to removed.
• .language is an abbreviation based on https://www.w3schools.com/tags/ref_language_codes.asp
• .LANGUAGEPATCH - any changes accumulating on top of MAJOR.MINOR for that language. No .language for english version as the source of all translations. So versions could be 1.0 1.0.es.2 . And then when we see main version 1.2 but translation still 1.0.es.2 we would know that we should update to the changes in that translation between versions 1.0 and 1.2 of the base version.

[CPernet]

the cons to me is the sheer volume - at the moment 6 languages for the ultimate consent form and 11 for gdrp consent form and 11 for the dua --> as you said, a minor change in 1 file needs to be carried out over many other files ; to me this outweighs the better traceability of changes

-- middle ground solution: have English in one file, all other languages in another (ie 3 English and 3 others)

[yarikoptic]

I don't get the too many files argument... Most likely not any single human would be able to change actual text in all languages at once. And even if needed - editors and sed can easily handle multiple files. Could you elaborate with an example?
Sticking all not English into a single file also doesn't help to solve any problem.

[CPernet]

ok fine, just been lazy ...
concretely, shall I make eg ultimate_french.rst doc/ultimate_french_gdpr.rst etc .. ?
if so should these files have a e.g. .. _chap_consent_french_ultimate: header as to list them automatically? let me know and I'll make them (we should do the same for all, gdrp version or not)

[yarikoptic]

eh, this discussion is more relevant to #43 ;-) but ok, let's continue here:
Let's follow abbreviations for languages? it would make appearance more consistent etc. Might be even worth sticking them all under i18n/ subfolder since otherwise would quickly becomes too busy. Something like:

• ultimate.rst
• i18n/ultimate.fr.rst
• i18n/ultimate.es.rst
• ...
• gdpr/ultimate_gdpr.rst
• gdpr/i18n/ultimate_gdpr.fr.rst
• gdpr/i18n/ultimate_gdpr.es.rst
  ...

? as for section ids -- the same, main section title + _abbrevlang, e.g. _chap_consent_ultimate_fr and _chap_consent_ultimate_gdpr_fr (although a bit occluding but _gdpr would never become a language abbreviation ;)) If we decide later on different names, it will be easy to change.

I could later script adding localized versions so does not need to be done during splitting to not introduce "bugs" (i.e. typos). splitting should really just move text around and possibly add section ids. Any changes to content should be done in separate PRs and later

[CPernet]

done

[yarikoptic]

Done where?

[CPernet]

through that same PR -- do I need to push it again? (did not look like you merged>?)
note updated both index as well

[yarikoptic]

note that whenever a PR gets merged, even if you push to that branch again - no new PR automagically created and old one is not resurrected. Since we did merge #40 before you pushed updates -- you had to create a new PR (which you did in #46)

[yarikoptic]

Apparently there was #27 which already exercised versioning a bit. It points to the fact missed there that there is 2 versions of the ultimate -- public and restricted. I feel that we should meld with #27, and also #45 (OBC prefix), and include ult|gdpr|dpi|dua while also adding ult-2t (for the restricted with two types of access), thus making it

• OBC-ULT
• OBC-ULT-2T
• OBC-GDPR-ULT
• OBC-GDPR-DPI
• OBC-GDPR-DUA

followed by the version which would include translation etc as described above: MAJOR.MINOR[.language[.LANGUAGEPATCH]]

[yarikoptic]

What do you think @chrisgorgo @CPernet @vborghe et al of @con/i18n ? ;)

[vborghe]

Sounds reasonable to me!