Architecture for translations

[jgroenen]

The current architecture contains all translations as folders in a single repository.
Maybe we can set it up so that each translation is in its own repo.
This way, I can create a clone and host it as my national "standaardvoorpubliekecode.nl".
In this case, I'd like a "central" menu page, to select a language (and then go to the URL for that language).

[jgroenen]

    graph TD
    A[Menu Page - translations.standardforpubliccode.org] --> B[English - standardforpubliccode.org]
    A --> C[Dutch - standaardvoorpubliekecode.nl]
    A --> D[Spanish - URL]

Loading

MENU:
[English]
[Espanol]
[Nederlands]

[jgroenen]

Something like this for translation.standardforpubliccode.org

[jgroenen]

I am removing the Foundation for Public Code references from the Jekyll template.

[jgroenen]

I am starting to need to make this switch/move. For the Dutch translation (community) there are some issues that need to be discussed, but because we are working on a fork right repo now, we cannot use "issues" there. This would mean that we would need to create Dutch issues in this repository, which to me doesn't make a lot of sense, especially when other language communities would start doing that too.

How can we decide if this is the way to go (and put the standard-for-public-code-nl repo in this organization)?

[jgroenen]

@ericherman do you perhaps have any thoughts on this?

[jgroenen]

PS. The "issues" argument was false - I was able to enable issues in the repo.

[ericherman]

@ericherman do you perhaps have any thoughts on this?

The notion of two repositories -- one for English, one for community (courtesy) translations -- seems like it could use some rethinking.

1. Since the introduction of the concepts of "authoritative translations" and "courtesy translations" the existence of incomplete or out-of-date "courtesy" translations no longer puts a codebase at risk for not meeting the standard.

2. Looking at the community-translations-standard repository, it can be seen that courtesy translations are not always kept up-to-date, and thus clear categorization by version is going to remain important.

3. A low-barrier-to-change index is good to help people find translations, but the people doing the translation work need to be able to collaborate on their translation without being needlessly delayed or blocked by low-availability of the English-language authors.

4. Perhaps somewhat similar to translations, adding additional context in the foreword or as an appendix has been requested in order to enable organization-specific adoption.

Whatever changes are made, I'd like to encourage thinking about what changes would recognize these things.