Bikeshedding on how and where to archive content

This issue is an “extension” of https://github.com/mdn/yari/issues/1076 digging more specifically into naming and organization.

The current plan (summarized here) is that we treat non-en-US content like we treat regular archive content (e.g. XUL). But we have options.

Certain is that we’ll have a github.com/mdn/content (aka. Content) repo that is going to be the source of truth replacing MySQL in the Wiki. That will only have en-us and it will only have non-archive content. Now we just need to figure out what do with things like

• /en-US/docs/Mercurial/Using_Mercurial
• /fr/docs/Web/JavaScript/A_propos
• /fr/docs/Améliorations_CSS_dans_Firefox_3

(not picking on French, just an example. instead of fr imagine it’s !en-us)

Splitting

Option 1

Create a repo for all things that are not en-us or not active content. E.g. github.com/mdn/archivecontent This would include things like /fr/docs/Web/JavaScript/A_propos

Option 2

Create a repo for all en-us archive content. And another for all non-en-us independent of active or archive slug. E.g. github.com/mdn/archivecontent and github.com/mdn/localizedcontent

Option 3

Create a repo for all en-us archive content. And another for all non-en-us active content. And another for all non-en-us archive content. E.g. github.com/mdn/archivecontent and github.com/mdn/localizedcontent and github.com/mdn/archivelocalizedcontent.

Option 4 (inspired by @escattone 's comment)

Create a repo for all archived content, independent of language. Another repo specifically for translated active content. E.g. github.com/mdn/archivecontent and github.com/mdn/translatedcontent

Naming

Let’s agree that the active en-us content should be simply called content. Eg. github.com/mdn/content.

Now, what do we call the other repos?

Option 1 (archiving)

archivedcontent

Option 2 (archiving)

archivecontent

Option 3 (translations)

localizedcontent

Option 4 (translations)

translatedcontent

Option combinations

archivedlocalizedcontent archivelocalizedcontent archivedtranslatedcontent archivetranslatedcontent

Options with hyphens

All the above could be hyphenated. E.g. archive-content or translated-content

Important notes

• It is very possible and quite realistic that we treat archive content different from non-en-us content. For example, on /ar/docs/Web/CSS we might wanna do things differently. For example, a different banner explain the state of the doc. This would be possible to if we lump translated content with archive English content.

• The archive content is likely never going to be useful and will die a slow death. But a lot of the now translated content we might use to train our machine learning service. For example, the Japanese and French translations in particular.

• We might have to update these things we archive (en-us or translated) because otherwise we might publish complete junk that is just embarrassing. So, we might have to deal with PRs on the translated content. Does it them help that it’s different from the split up?

• Too many repos hurt the brain. Too few makes them into monsters since they’ll contain the the rendered HTML which is often huge.

[peterbe]

@escattone and I had a lengthy discussion on this and have now decided on all the names and splitting. Here it goes.

2 new repos (beyond the content one):

• archived-content: Everything that’s considered archived based on the slug, independent of the locale
• translated-content: Everything that isn’t active English or archived

Note the use of the:

• hyphen
• distinction that “content” is a suffix rather than a prefix/namespace
• “archived”, not “archive”
• “translated”, not “localized”

Thank you all for your help! Much appreciated.

[ddbeck]

@peterbe the main thing to me is showing that the repos are, in fact, related. I do feel like there should be a common prefix for them, especially if stuff is expected to cross repo boundaries (e.g., moving something from content → archive). Maybe web-docs-content, web-docs-archive, web-docs-translations?

(If GitHub gave us literally any other way to group repos within an org, I’d probably be a bit more relaxed about it.)