Plans for The Transport Tycoon Wiki

[michael blunck]

Well, with regards to the highly acclaimed "multilingual" approach of MediaWiki: Don´t confuse cause and effect.

Yes, it´s true: TikiWiki, used by TTDPatch´s Wiki, doesn´t support translations explicitly. But o/c, it´s simply possible to have texts in other languages than English on the Wiki, and to reference them by appropriate links. The real question however, would be who´d write those translations/texts, if we had a "real" "multilingual" Wiki?

Now, don´t answer this in the usual repetitive way: "It´s a Wiki!", because even now, it´s quite possible to add non-English pages to the existing Wiki. And take a look over to the OTTD Wiki which is "multilingual" from the outset: how many non-English texts have been included there over the years? Astonishingly few. So, I see this in the usual way: someone proposes a "new" feature and the crowd joins into it, verbally - not by doing.

Now, to some of the other mentioned "downsides" of TikiWiki (table spans, history function). When first setting up the TTDPatch Wiki, Josef added a lot of improvements to the then used version of TikiWiki, he even sent patches to the TikiWiki project, but apparently, none of them had been implemented. Nevertheless, some of those mentioned "downsides" have been removed recently by simply reconfiguring the Wiki (history function).

I have even discussed the migration of TikiWiki to MediaWiki with Josef some weeks ago, and the consensus then was "it´s too much work for too little benefit". Now, a much larger workload seems to be eagerly accepted with a doubtful extra of "little benefit"?

With regards to non-English texts on the TTDPatch Wiki, questions had asked often whether it´d be possible to have the TTDPatch manual and the ECS vector´s documentation in other languages as well (namely German, see Lord´s post). These two parts of the Wiki could indeed stand to benefit from a translation. But again, the question is not if this would be technically feasible (it is), but who would translate/write those texts?

W/r to the nfo/grf specs, a translation for this section seems not to be needed at a premium, because usually everyone with some knowledge in programming does understand enough English to be able to use the spec. This is the main reason that there has never been a German translation (although some developers are native speakers of German). "It´s not worth the effort."

regards
Michael

[Yexo]

The real question however, would be who´d write those translations/texts, if we had a "real" "multilingual" Wiki?

Now, don´t answer this in the usual repetitive way: "It´s a Wiki!", because even now, it´s quite possible to add non-English pages to the existing Wiki. And take a look over to the OTTD Wiki which is "multilingual" from the outset: how many non-English texts have been included there over the years? Astonishingly few. So, I see this in the usual way: someone proposes a "new" feature and the crowd joins into it, verbally - not by doing.

But it is a wiki! According to http://wiki.openttd.org/Category:Other_languages there are currently over 800 fully translated pages, with 300 more pages in progress. I wouldn't call that insignificant. For German the complete tutorial is translated, see http://wiki.openttd.org/Tutorial/De

I have even discussed the migration of TikiWiki to MediaWiki with Josef some weeks ago, and the consensus then was "it´s too much work for too little benefit". Now, a much larger workload seems to be eagerly accepted with a doubtful extra of "little benefit"?

Maybe you can Josef think it's too much work, that doesn't mean other can't see more benefit. Also as long as orudge is wanting to do it it shouldn't be any work for either you or Josef, so that's no argument not to do it.

With regards to non-English texts on the TTDPatch Wiki, questions had asked often whether it´d be possible to have the TTDPatch manual and the ECS vector´s documentation in other languages as well (namely German, see Lord´s post). These two parts of the Wiki could indeed stand to benefit from a translation. But again, the question is not if this would be technically feasible (it is), but who would translate/write those texts?

I'm not sure if there are enough people playing TTDPatch to also translate that manual, but if you push even a little bit you should be able to get ECS vector's documentation translation in at least a few languages. Again, see the amount done on the OpentTD wiki already and if it becomes easier it'll certainly be done.

W/r to the nfo/grf specs, a translation for this section seems not to be needed at a premium, because usually everyone with some knowledge in programming does understand enough English to be able to use the spec. This is the main reason that there has never been a German translation (although some developers are native speakers of German). "It´s not worth the effort."

I agree that the specs should not be translated. Having the spec in multiple languages will only add to any confusion and it'll be hard to keep multiple translations in sync (which is not a problem for a manual, but it is for a spec).

[frosch]

Just to second Yexo's post.
The translations on the OTTD wiki actually only started a year ago or so.

And yes, the NewGRF specs should not be translated at all. It is hard enough to keep the current ones consistent and correct.
But the NewGRF tutorials could be translated nevertheless.

[planetmaker]

Generally I think this can be a good idea, the question IMHO is more about the details of what it entails:

* Most user friendly would be a single sign-on for the diverse services (tt-forums, OpenTTD, this wiki). This might not be easy, but it's probably feasable.
* A common wiki for all involved projects (OTTDP, Locomotion,...) might have the potential for a few synergies, I can especially imagine it in the graphics drawing section; quite a few people seem to play also several games, so yes.

* Another important point might be (and should be) translations which just started to appear in the OpenTTD wiki in the last 12 months. Not sure the solution employed there is the best solution, maybe there's a better one (which?), but it is a solution to translations and it seems to work somewhat, at least better than no translation and it allows successive translation of the English main wiki.

* Converting the NewGRF wiki to a media wiki sounds IMHO promising too as the tikiwiki has quite some things which I miss(ed), they were named in a posting above already. But as emphasized by nearly all, this part should not require or have translations as it's our reference and it must remain so.

* If the OpenTTD wiki is not being merged, IMHO a single sign-on becomes even more important so that people can easily continue in the part which they can make a contribution to, whereever that is (game mechanics game A, game mechanics, game B, drawing tutorial, translation...)

[Born Acorn]

Generally I think this can be a good idea, the question IMHO is more about the details of what it entails:

* Most user friendly would be a single sign-on for the diverse services (tt-forums, OpenTTD, this wiki). This might not be easy, but it's probably feasable.

I believe Mr Rudge already has this planned.


If there are no big ojections, then maybe the OpenTTD wiki should be merged too? I mean, in the past there were talks of OpenTTD being "separate", so far as splitting off to new forums elsewhere (this was years ago). I think MediaWiki can import from another MediaWiki easily?

[DaleStan]

Now, don´t answer this in the usual repetitive way: "It´s a Wiki!", because even now, it´s quite possible to add non-English pages to the existing Wiki. And take a look over to the OTTD Wiki which is "multilingual" from the outset: how many non-English texts have been included there over the years? Astonishingly few. So, I see this in the usual way: someone proposes a "new" feature and the crowd joins into it, verbally - not by doing.

But it is a wiki! According to http://wiki.openttd.org/Category:Other_languages there are currently over 800 fully translated pages, with 300 more pages in progress. I wouldn't call that insignificant.

For an average of 35 complete and 14 in-progress pages per language. There are also roughly 2500 English-language pages. Welcome to the wonderful world of "About 2% complete".
As for individual languages, the most complete one is about 15% complete, and the second is about 8% complete.

The translations on the OTTD wiki actually only started a year ago or so.

So, at the current rate, you'll have your first complete translation sometime second half of 2016, and the next one in 2022.

Might I suggest that these numbers are possibly not as glorious as you seem to think? There may well be glorious numbers, but these are not those numbers.

[CommanderZ]

For an average of 35 complete and 14 in-progress pages per language. There are also roughly 2500 English-language pages. Welcome to the wonderful world of "About 2% complete".
As for individual languages, the most complete one is about 15% complete, and the second is about 8% complete.

Irrelevant.

See this.

The ratios are not that much better for real Wikipedia. EN has 3.4M articles, DE has 1.1k which is about 30%, followed by 1.0M and 700k. What matters most is if the 5% (or perhaps even less) of key articles are there.

EDIT:

Also, another important factor is that TTD wiki is bound to be relatively small. Several dedicated guys can create a translation within relatively short time span. As others said, the translations are only being done for a year or so.

[Hyronymus]

Bickering about multiple language support, how wonderful.

If you can install a Wiki that does allow multiple languages I think you should, even if you don't fully implement it right from the start.

Also, the fact that there aren't much translated pages in the current Wiki doesn't automatically mean there won't be a demand for it in the new Wiki. Agreed, one cannot claim it will be in demand either but it's not possible to completely rule out unawareness of the room for translations on the current wiki.

[eis_os]

Owen: You still haven't made a common login system for tt-forums service since ages.

Wiki:
The TTDPatch wiki uses templates and we have used the bug tracker more or less. So while the TikiWiki software isn't peoples favorite it used be a good software for the TTDPatch Project at that time. Neither do I like mixing OTTD or TTDPatch content. People are already confused by both Projects.

GRFCrawler
Theoretical GRFCrawler was able to search other data "providers". I haven't seen a specs for Bananas and writing a c client to connect to bananas is nothing I want to invest. I have a unstable GRFCrawler version with preliminary upload/download support, multi-owner-entries and some new categories but simply don't have time to finish it and I don't see enough support for GRFCrawler lately. As soon as the cost for supporting GRFCrawler will be higher then the community value I may take this project offline too.

We have seen GRFCrawler sometimes lose the TT-Forums login system link and I don't like designs with a single point of failure.
GRFCrawler is using tt-forums infrastructure for the single sign on system, otherwise I would host it myself.

The wiki approach for GRFCrawler didn't work. People could propose new entries without user accounts in the beginning. That was a disaster...

Note: My opinion doesn't count much, so do what you like as I don't feel like to be part of the community anymore anyway.

PS: The ECS Vector content isn't something I really liked in the ttdpatch wiki in the first place. No one stops the OTTD users and dev to copy the content and do it "right" on the ottd wiki...

[orudge]

Whee, lots to get through...

A single login between openttd.org and tt-forums.net / tt-wiki would already go a long way towards integrating the openttd wiki also. If you just have to login once it'll become much easier to create inter-wiki links and edit pages in both wikis.

I think that would be preferable, indeed. I did create a basic single-sign on system for the forums a couple of years ago. It's not seen any live use, and hasn't been tested much since then, but fixing that up and perhaps looking into getting the OpenTTD user database merged into the tt-forums database, and switching OpenTTD to use this authentication system, would likely be good. A reasonable bit of work, though.

The newgrf specs on the ttdpatch wiki are currently the official reference. Currently that works fine, but this might in part be because you have to create a different account to edit it. When merging that wiki it'll become much easier to change the newgrf specs, leading to even more discussions what is the right interpretation of the spec.

It would be possible to lock the specification pages down a bit, to only allow it to be edited by a nominated usergroup. Might be worth doing.

You should consider a wiki that supports a multilingual setup. People will eventually ask for it, and if it isn't possible try all kinds of ways to "implement" it.

With the OpenTTD wiki being the largest, then it would seem to make sense to base this new wiki on the current OpenTTD wiki, and merge the other content into that (which is pretty straightforward). Therefore, the multilingual setup that's already been used can be easily extended.

Merging OpenTTD's wiki with that new wiki would mean merging user accounts between openttd.org and tt-forums.net. I'm not sure how viable that is.

How many users are registered in the OpenTTD account system at the moment? It would certainly be possible to merge the accounts, although it would involve, as mentioned before, a bit of work and coordination.

Possibly the NewGRF specification part of the wiki could be separated a bit more so making an archive with the whole specification would be quite easy, like is done with the tiki wiki. That way the NewGRF specification would be available offline as well.

I imagine we could give the NewGRF pages their own page title prefix, which could then be exported relatively easily.

Well, honestly, I fail to see a good reason for integrating that largely different stuff. What, e.g. is "the TT-Forums wiki"?

That'd be http://wiki.tt-forums.net/ - it's more of a "community wiki" than a TT wiki at the moment, and isn't widely used, but it is there, and has been for a good few years now.

And I don´t think that "the Locomotion Depot wiki" would have large intersections with TTDPatch, or TTD at all.

Maybe not, but we already host the Locomotion forums, so I don't see why we couldn't host the wiki as well.

I do not understand how orudge concludes TikiWiki would be more advanced, I only hit limitations.

Well, TikiWiki appears to be significantly more extensible than MediaWiki, but to be honest, most of those extensions I don't think we're going to need anyway.

* Most user friendly would be a single sign-on for the diverse services (tt-forums, OpenTTD, this wiki). This might not be easy, but it's probably feasable.

I think this would be the first place we want to start. Again, there are two parts to this. The first is merging the OpenTTD users into the forum database. The second is adjusting the OpenTTD services so that they use the forum database.

As I mentioned before, I did write a PHP-based single sign-on library for the forums (ie, you log into one site, and you're logged into all of them). It mostly works in my testing, but there are some issues with mixed IPv4/IPv6 setups, unfortunately. I'm not sure quite how feasible they will be to fix without sacrificing security (ie, dealing with potential session hijackings), but I'll need to go back and look at that again. Anyway, assuming I get that working nicely, it in theory should be very simple to integrate with MediaWiki, Flyspray, etc. It obviously won't integrate with non-PHP stuff, though, which is an issue for Bananas.

For the sites that can't easily be integrated with the SSO library, shared authentication is of course possible, and is technically somewhat simpler - you'd have to log in directly to the other sites, rather than being able to use a common login page, but you'd still be using the same details as you would on the forums. The site would then communicate with the forums via a secure channel and verify the user identity. This would still require some custom coding, though, as it's not using a "standardised" protocol.

(Probably the simplest solution would be to simply expose the forum user database over LDAP, as OpenTTD uses LDAP already, but from the point of view of the forums, that would be extremely difficult, unfortunately, and I don't think it would be practical.)

Owen: You still haven't made a common login system for tt-forums service since ages.

See above.

The TTDPatch wiki uses templates and we have used the bug tracker more or less.

We'd have to do something with the bug tracker, indeed. Obviously, MediaWiki doesn't contain any kind of bug tracker. Potentially the bugs could be migrated to an installation of Flyspray for TTDPatch, or maybe Tiki could even be kept for the bugs only, with the wiki disabled (and integrated with the tt-forums user system). This'll need to be considered.

Neither do I like mixing OTTD or TTDPatch content. People are already confused by both Projects.

That is true, but particularly these days, there is a huge amount of overlap between both projects, and it seems a bit silly to duplicate content that doesn't have to be. I think the new wiki would have to have very clear infoboxes or whatever to distiguish between OpenTTD and TTDPatch features, or differing implementations in both games. I don't see that that should be impossible, though.

Theoretical GRFCrawler was able to search other data "providers". I haven't seen a specs for Bananas and writing a c client to connect to bananas is nothing I want to invest. I have a unstable GRFCrawler version with preliminary upload/download support, multi-owner-entries and some new categories but simply don't have time to finish it and I don't see enough support for GRFCrawler lately. As soon as the cost for supporting GRFCrawler will be higher then the community value I may take this project offline too.

GRFCrawler is a really essential resource, I would say, so even if you're not going to be able to support it, please don't take it offline. There are certainly others who can help support and maintain the site.

We have seen GRFCrawler sometimes lose the TT-Forums login system link and I don't like designs with a single point of failure.

While that's understandable, it is very rare for the forums to be down, and the issues GRFCrawler has had has more been due to the way the single sign on has been implemented for GRFCrawler (combined with certain MySQL oddities). The proper system I've been working on should work as long as the forums are up - i.e., no MySQL connection issues.

----------------------------------------------------------------------------------------------------

To summarise, I think that the next step ahead would probably involve me finishing/finalising the SSO system, and/or a shared authentication protocol. After that, we can potentially look into how we can merge OpenTTD accounts into the forums, and getting the OpenTTD services authenticating against the forum database.

If the decision is then taken that the OpenTTD wiki should form the basis of the new wiki, it could then be "rebranded" as the TT Wiki and reorganised to add appropriate sections for TTDPatch, Locomotion and the general community, or whatever seems best. (Of course, the wiki can still have "Main Pages" for each individual project, with an overall main page providing links to each one.) I can then import the TTDPatch pages, and we can work on integrating them all into the new wiki properly. The same would then happen with the Locomotion wiki, and the tt-forums wiki.

If that doesn't end up happening, then we can at least migrate the existing wikis over to the tt-forums authentication system in the mean time. Personally, though, I do think it would be better if they were unified, but we need to do it "properly".

Thanks for all your comments. If you have any further thoughts, do let me know!

[Lord Aro]

One (extremely minor) thing that occurs to me is that the OTTD login system doesn't allow spaces in usernames, hence why i am 'Lord Aro' here, and 'LordAro' over there
Just thought i'd mention it...

[orudge]

My vague intention would be to reconcile users via a combination of username and e-mail address; if duplicates still remain then they can be merged manually, so don't worry too much about that.

[eis_os]

It do think it is up to the users how stuff they like you may want to start a dedicated poll. As we already did lose some important parts while translating from newgrf.txt to the TTDPatch Wiki I had to dig and clarify later so I prefer to get a database dump of TTDPatch Wiki content for my "private" archive in it's current state.

[Hyronymus]

A poll is a good idea but don't we need a clear proposal to votew on first? There have been many comments and suggestions that are necessary to look into (especially the restrictions on normal forum users being able to manage wiki entries).

[wallyweb]

Some observations from an inveterate user of the wiki and the forums:

1. STICKY THIS FORUM - It is too important to let it float away.
2. orudge - Exercise your dictatorial powers - Take control of the discussion - Set a plan of action!
3. I am currently quite comfortable with things as they exist with perhaps a few minor adjustments, but then I am an old fart (duly licensed as such by the Government of Canada) whose resistance to change grows in direct proportion to one's growth in arthritis. That said, I AM open to change that is well reasoned and not done merely because a change is possible.
4. It would seem that the initial challenge is some sort of commonality of registration/login. It would seem that orudge has a handle on this. The question is, once logged in, where does the visitor go from there?
5. The next consideration would be an overall structure ... An index or a contents page should fulfill this function quite nicely. Once done, it would be a simple matter to append the various section pages (or links to same if they lie outside the wiki).
6. Much has been made of translations. First, a default language to start from ... English would seem to be the most logical. All new content should first be done in the default. Thereafter, with a suitable interface/accommodation, translations could be written/implemented by those most desiring of a particular language.
7. Is a pole really needed to implement any of the above?

Now a word of caution ... Wikipedia has been mentioned. It is a fine tool but it has one failing ... an occasional incidence of overmoderation. There is no question of the need for moderators, especially in the area of spam control. Unfortunately, there will also be the occasional temptation towards content control. While a necessary evil, to delete some content with a simple "IRRELEVANT" given as a reason is unacceptable. Any moderation should/must be accompanied by a thorough reasoning.

What would I like to see included? The TTDPatch manual, A grf source page (GRFCrawler works for me), NFO specifications (How to write code in HEX, How an Action is structured, How varAction2's work, the Palettes ...), NewGRFSpecifications with examples, Copyright/licensing considerations(1), Similar information for OpenTTD, Locomotion, and any other platform to be considered, Current links to tools such as GRFCodec, nfoRenum, GRFWizard, etc.

I've probably missed a few items, but they'll come out in the discussions.

Oh yes, one more thing ... Nothing is set in stone. All suggested changes must be considered. (I can't believe I just said that. )

EDIT (1) Copyright/licensing - The TTD games are based on proprietary material. How to handle this (with examples?) would resolve a lot of opinion currently scattered about the forums. Links to GPL and Creative Commons would be helpful too.

[Valentijn]

Why not go for a "pro" wiki like confluence? It's free for open-source projects like openttd... I am not sure how ttdpatch and all would fit in and whether they still use copyrighted stuff?

[CN_Rail]

You'll need to be registered on the forums to be able to edit the wiki. We may introduce other anti-spam mechanisms if they prove to be necessary.

Good idea orudge, because I find that's a recurring problem with many wikis; people vandalize them. But how are you going to do that? Most wikis that I've seen don't require you to be logged in to be able to edit pages.
As an extra precaution, may I suggest that you put a place where you have to be able to read a word or two in blurry text whenever you edit? With all this anti-spam stuff, the wiki will be as great and as spam-free as the forums.

[planetmaker]

Why not go for a "pro" wiki like confluence? It's free for open-source projects like openttd... I am not sure how ttdpatch and all would fit in and whether they still use copyrighted stuff?

What makes you think that mediawiki is not "pro" when it is used successfully for the largest wikis found in the entire internet?

Good idea orudge, because I find that's a recurring problem with many wikis; people vandalize them. But how are you going to do that? Most wikis that I've seen don't require you to be logged in to be able to edit pages.

It works quite successfully on the current OpenTTD wiki without (luckily) much vandalism. When not logged in, you'll have to go through solving captchas, otherwise you're free to edit without that hassle.

[CN_Rail]

Sorry I just have one more quick point...I hope it's not spam, if so I'll remove it.
Is there any mechanism to prevent souls from entering the forums that know nothing about Transport Tycoon or Locomotion? Otherwise what's the good of making sure people register to edit the wiki if you don't have to know anything about the games to register in these forums.
I don't recall having to enter a serial number when registering, any suggestions?
Otherwise the idea is great!

[DaleStan]

Entering serial numbers has a slight minor little problem: None of TTO, TTD, TTDPatch, or OpenTTD have serial numbers.