Just like the main Civilization games are played around the world, NQMod and enjoyed by people many different countries. Interest has been shown in translating the wiki to help the project reach even more people. To do this right, we will need a system in place for organizing and delivering those translations.
I'm putting down my thoughts here on how this can be done. I hope to get community feedback on the topic, and maybe inspire some would-be translators to pitch in!
Option 1: Separate (Official) Wikis
Wikia has feature support for officially linking alternate language wikis.
- Probably a better user experience, especially for those who don't speak English. Everthing including the wiki's & Wikia's headers and links will be in the user's language.
- Built-in Wikia interlanguage linking system can be used instead of needing a custom system.
- Wikis can be customized in visuals and content to suit their community.
- Community features (discussions, blogs, etc) can be used to address specific needs and issues that might otherwise be lost in a unified wiki.
- Community features in their language may be more welcoming to users.
- Organization - pages, category pages, templates, databases, etc kept on their own site are likely easier to sort through. There will be less errors when doing things like categorizing a page if there aren't multiple language specific options. Recent activity feeds will be local rather than a bloated combined feed.
- More content will need to be ported to the new site, including backend tools like templates.
- Note: Images will not need to be ported, there is a system where images can be shared.
- Each wiki may be updated at a different pace - it will be up to that community's editors and admins to manage its individual site.
- Updates to backend tools like shared templates will need to be reflected on each wiki. This could be a simple copy/paste or may require formatting.
Option 2: Sub-wikis
Rather than creating whole new wikis, translations could be kept either in sub-pages (/wiki/PAGE/LANG) or nested in sub-wikis (/wiki/LANG/PAGE).
- All content on same site
- A tabbing system could be used to show everything on the primary page, transcluding the translated page into its tab.
- Minimizes duplication, especially on the backend where templates can be reused, and similar busy work with setting up a new wiki site.
- Streamlines site upkeep. Template and database updates, new features, etc will happen simultaneously regardless of language. When a new mod update is released its information will at least be available in English if the translation lags behind.
- Unified community features (discussions, blogs, etc) increases potential users, avoids division and dilution of conversations regarding the mod or wiki.
- Less need for individual admins and management would be limited to the single wiki.
- Everything outside page content would be in English: Wikia & wiki headers and links, page urls and names (if using unified tab system), etc.
- Tabbing system / multiple languages on the same page would bloat the pages slowing down load times.
- Editing can be more complicated - new editors may edit the primary page intending to change a transcluded one, multiple templates per page for each language could be confusing, etc.
- Could disrupt page navigation & wiki features: Inaccurate page count, potential categorization and linking issues, etc.
- Unified community features could exclude those unable to or uncomfortable with speaking English.
- Admins may get overwhelmed by the additional content to manage and users may have issues finding an admin that can help them in their own language.
The Lua-based templating and database systems that I've been working on are nearly usable. As these systems are completed they can be used to streamline wiki translation. Translating database text values would vastly cut down on the need to update things like infoboxes page-by-page.
Deciding to use these database templates vs more traditional templates should be left to each translating community's editors. While updating the databases shouldn't require coding knowledge, the possibility of simple mistakes (like a missing comma or extra ']' closing bracket) breaking multiple pages may be daunting. Users should use what they are comfortable with - the content is more important that the system to deliver it. Another editor can later use those translations to update the database should the community decide to switch over.
Regardless of the chosen delivery system, the content that needs translation should be largely the same.
There are 3 types of content that will require translation:
- Infobox & table headers, labels, etc
- Other textual content
- Database text values (if using databases and their templates)
- Content written directly to a wiki page
- Changelog pages
- Page sections like descriptions, strategy, etc
- Page structure such as headers
Before jumping into a new translation project and publishing content, I recommend contacting an admin to get things set up. This will involve creating either a sub-wiki or making & linking a new wiki, then prepping categories, templates, and databases.
I'll be making a template to assist page creation and linking. It should show a list of each English page and its corresponding page in the target language. If using translated page names (in a sub-wiki or separate wiki) this would require making a database with each language's pages. Translating those page names would then be a good place to begin, to get the correct links from the template and so the database could be used to automate interlanguage links.
After that content translation can begin. The Discussions forum can be used to plan and organize translation projects with other editors, and you can ask if anyone is interested in helping over on the NQmod subreddit. Remember that these wikis are a community effort, so don't hesitate to ask for help when you need it or don't understand how something works.
I think it would be great to have the wiki translated, but before we get too far into it a decision has to be made: one unified wiki or separate specialized ones?
Personally, I'm leaning towards separate wikis. I think the built-in features look great, and the added organization, user experience, and reduced wiki and page bloat should offset the loss of backend consistency and unified community sections. We may start one as a test case - the decision can be reversed depending on feedback and how it goes.
What do you think? Feedback will be welcome even after start. Even if you can't help out with a translation project, share if you think this is useful and any ideas you have. The support can go a long way in encouraging editor interest.
Thanks for reading, happy Civing!