I've started moving the interface and the basic behaviour from the prototype into the production repository, to get it ready for development.

I didn't copy any files across. I used the prototype as a reference for how things should behave and look, then wrote each piece again in the production site, keeping it small and easy to read.

I put a bit of emphasis on:

• Keeping configuration separate from the code that uses it, and from the data (including generated data)
• Keeping each piece clean and easy to maintain
• Adding CSS variables, so design decisions are easy to change later

Writing it again took a bit more time, but the result is much smaller. A few examples:

• "On this page" (the list of sections on a page) is about 120 lines here. In the prototype it's around 450. I take the list from data the page already has, instead of reading the finished page in the browser and watching it for changes.
• The side menu doesn't need its own configuration. The same menu tree that draws the top menu also draws the side menu, so the site is only described once.
• The language list comes from the Wikimedia API, through a script I run by hand, and the result is saved in the repository. The prototype had four languages typed in by hand. There are now 575, and nobody has to keep them up to date.

The point of all this is maintenance. Someone joining the project later should be able to open a file, see why it's built that way, and change one value in one place.

What's migrated

Pages and text

• Markdown pages in any language, with one route handling all of them
• Page styling (headings, lists, tables, code, quotes, images)
• All interface text goes through a translation system (74 messages so far), and every one has a description written for translators
• If a page exists in English but not in your language, you get the English version and a note saying why, instead of an error
• An error page, in the site shell and in the reader's language

The page shell

• Header with the Wikimedia mark and the site name
• Top menu, built from one configuration file (42 destinations, 9 headings)
• Side menu showing the pages in the section you're reading
• "On this page" list of the page's own sections
• Footer with the content licence, privacy policy, terms of use and code of conduct
• Light and dark mode, with a control in the header to pick one
• Language picker in the header, showing only the languages the site serves
• Everything works right to left (try /he/)
• Everything works on a phone, a tablet and a desktop

Under the surface

• API reference embedded and styled (Scalar), at /_dev/api-reference
• A catalogue of 575 languages, generated from the Wikimedia API by a script.
• A language is only displayed in the UI list once enough of it is translated (threshholds that are defined in config variables). The percentage is counted on every build from the message files themselves, so adding a language just means putting its file in place. There's no list of languages to keep up to date.
• Two separate thresholds, one for interface text (buttons, labels) and one for page text, so the two can be judged differently. Both are 75% for now. The interface one is working. The page text one is ready and waiting, because translated page content doesn't exist yet.
• Once a language qualifies it stays, even if its percentage drops later. There's a note below on why that matters.
• Every page is built as static HTML, so reading a page never waits for JavaScript
• Automatic checks on every merge request: tests, types, translator documentation, generated files
• A Netlify preview for every merge request, so you can look at the work without installing anything

NOTE: We should think whether the language threshhold consideration should be done on build (as it is right now) or maybe by a dedicated script pre-build so it can be reviewed and managed if/when languages are added or dropped. The current script is supposed to retain existing languages even if they dropped from threshhold, but depending on how often this happened, making this operation part of a pre-build process *might* help us control and validate for it better. This is just something to look for as we go.

Note: Decision was officially made to *not* have to import any wiki pages into markdown for the prototype. I removed all the checkboxes that related to that, but just in case I missed any -- it is no longer a requirement.