The volunteers behind the Wikiconference wiki and the Wikimania 2014 Wikis have both shared their insights on the design and the structure. When it comes to the Wikimania 2014 Wiki:

wikimanialondon.org forwards to the wiki site, to make it more attractive and easier to navigate to
relatively attractive landing page & styling throughout: https://wikimania2014.wikimedia.org/w/index.php?title=Wikimania&oldid=48699
deep linkable programme page: https://wikimania2014.wikimedia.org/wiki/Programme#Saturday,_August_9
pages for each conference theme, e.g.: https://wikimania2014.wikimedia.org/wiki/Open_Data
attendees directory: https://wikimania2014.wikimedia.org/wiki/Hello_world

I personally also think that the Wikimania 2017 Wiki looks good, I prefer when they are not too long.

When it comes to the Wikiconference website, there is a

distinct system of page titles, Lua modules, and categories to "namespace" the different years of the conference while making it look like they're on the same site. We then update the sidebar links to point to these year-specific pages and create redirects as needed.
Example:
https://wikiconference.org/wiki/2018/Schedule was the schedule for last year's North America conference. The page is technically called "2018/Schedule" to distinguish it from the 2017 schedule,
https://wikiconference.org/wiki/2017/Schedule. Each of these pages have year-specific templates: https://wikiconference.org/wiki/Template:2018 https://wikiconference.org/wiki/Template:2017 which invoke a Lua module to strip the >year prefix out of the page title https://wikiconference.org/wiki/Module:YearStrip. (The templates also add taglines specific to that year's conference.)

Do you have any examples you prefer that could work as models?

The one thing that has been tumbling over in my mind is now that there is one wiki for many years, there will need to be the hierarchy to cover many years. In previous wikis, they could do it all one level down from root, and not have to worry about next year, that is no longer the case.

Will it be
2019/Schedule
2019/Volunteers

or
Schedule/2019
Volunteers/2019

or something else

If you do all at base level, then think that you can move it at the end then the relative links and link fixes are going to be awful, and prone to breakages. We can be looking to just have redirects at the base level so that each default redirects down, and that changes per year. Also could affect how templating is done, so it will need to considered early.

WikiConference North America does “Year/Pagename” e.g. “2018/Schedule” along with per-year templates that strip out the year prefix in the displayed page title and add a year-specific tagline. We have done five of these conferences now and this system has worked well for us.

In T215031#4920987, @Harej wrote:

WikiConference North America does “Year/Pagename” e.g. “2018/Schedule” along with per-year templates that strip out the year prefix in the displayed page title and add a year-specific tagline. We have done five of these conferences now and this system has worked well for us.

Great that there is a model to view. [insert some sort of thumbs up meme!]

In T215031#4921038, @Trizek wrote:

Don't forget to import translations if you import things that were marked for translation.

I currently doing that for gadgets, and setting up the framework for mediawiki: ns messages (as they cannot sit in the translation toolset as I see it)

We have an issue we need to carefully take care of by design: translatability (for internationalization) and sustainability around i18n. I've been thinking about how to organize the contents with a “Year/Pagename” system combined with Extension:Translate. It is not really matching I'm afraid.

So we need to define some clear rules before thinking about the structure of the pages.

• Which pages are supposed to be changed every year?
• What is the most important between archiving old contents and reducing translation effort?

Those question don't apply to things that are unique to one year: the presentation of the venue, submissions, etc.

Some pages can exist without much changes on translations. For instance, we can design the Home page or the Hackathon page to exist without massive changes each year. It is possible to just change practical information but not the "speech" around. That would however require to have a page that is not archived but that evolves year after year. It is a decision to make.

The use of “Year/Pagename” works great for a monolingual case, where you create a new instance every year. The evolution are simple to make: you can copy the content from the previous year and then freely update it. But will it scale to that new wiki that works on translations as much as possible? Are we doing to ask people to translate every year some contents that could be kept if they are well designed (I'm excluding interface messages there)? We should think carefully on how to have "sustainable" interface and contents.

If you import things from the previous years that have been marked for translation/were translated, don't forget to import the translations of contents as well. It should be done even if some elements have been changed, because it is easier to get the text ready to be changed. It is possible in Extension:Translate. I could handle that with the right rights if they are granted to me.

@Trizek That's a great comment. My initial reaction would be that the translation recommendations available on Meta, given that they will work also on the Wikimania wiki (?), at least partly will solve the problem? I'm not an expert on how that works, so please tell me if I'm wrong. But a text matching 100% should presumably, I suppose, be a text that hasn't changed since last year? Would it be possible to have a bot run through all texts that match 100%, leaving translations to be made manually for the rest?

Which pages are supposed to be changed every year?

I started a draft page directory in T214888; perhaps it should be transfered to the Wikimania Wiki or elsewhere for more thorough discussion.

In T215031#4920932, @Billinghurst wrote:

The one thing that has been tumbling over in my mind is now that there is one wiki for many years, there will need to be the hierarchy to cover many years. In previous wikis, they could do it all one level down from root, and not have to worry about next year, that is no longer the case.

Will it be
2019/Schedule
2019/Volunteers

or
Schedule/2019
Volunteers/2019

or something else

If you do all at base level, then think that you can move it at the end then the relative links and link fixes are going to be awful, and prone to breakages. We can be looking to just have redirects at the base level so that each default redirects down, and that changes per year. Also could affect how templating is done, so it will need to considered early.

Each year will have a namespace (2019s already exists) on the new wiki, so it can still work that, instead of (Main NS):2019/Schedule it would just be 2019:Schedule the namespaces that people will need to be careful will be Template, File, Category etc.

From memory, I have also read that the search system has been set to default to the 2019 namespace as well.

In T215031#4921397, @Peachey88 wrote:

Each year will have a namespace (2019s already exists) on the new wiki, so it can still work that, instead of (Main NS):2019/Schedule it would just be 2019:Schedule the namespaces that people will need to be careful will be Template, File, Category etc.

From memory, I have also read that the search system has been set to default to the 2019 namespace as well.

Excellent

https://wikimania.wikimedia.org/w/api.php?action=query&meta=siteinfo&siprop=namespaces%7Cnamespacealiases

ns:128 for wm2019

"128": {
    "id": 128,
    "case": "first-letter",
    "canonical": "2019",
    "*": "2019"
},
"129": {
    "id": 129,
    "case": "first-letter",
    "canonical": "2019 talk",
    "*": "2019 talk"
},

@Peachey88 is there a plan and/or timetable to migrate these other years to the other namespaces (for the previous years)? Just so we know what we are going to have to import from existing wikis, or not bother

In T215031#4921506, @Billinghurst wrote:

@Peachey88 is there a plan and/or timetable to migrate these other years to the other namespaces (for the previous years)? Just so we know what we are going to have to import from existing wikis, or not bother

See T202684: Import the old per-year Wikimania wikis into the new Wikimania wiki, each under their namespace

Isn't a request to close a wiki => removing Wiki-Setup (Create) and my personal project.

(Sorry, I4ve been off and very busy the last days.)

In T215031#4921388, @Eric_Luth_WMSE wrote:

@Trizek That's a great comment. My initial reaction would be that the translation recommendations available on Meta, given that they will work also on the Wikimania wiki (?), at least partly will solve the problem? I'm not an expert on how that works, so please tell me if I'm wrong. But a text matching 100% should presumably, I suppose, be a text that hasn't changed since last year? Would it be possible to have a bot run through all texts that match 100%, leaving translations to be made manually for the rest?

You mean importing things from Meta? We can import any content that has English as source and some translations. In my mind, the goal of keeping translations from previous Wikimania wikis is to spare a long translation work for translators.