User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 StumbleUpon/1.9991 Build Identifier: Devmo has an English wiki at http://developer-test.mozilla.org/docs/ We also need two other wikis in the very near future: one French and one Japanese. If possible, these wikis should be set up at: developer-test.mozilla.org/fr/docs/ developer-test.mozilla.org/ja/docs/ For consistency's sake, the english wiki should probably eventually be moved to: developer-test.mozilla.org/en/docs/ Configuration files will also have to be set up to take advantage of the Interlanguage linking facilities in MediaWiki...more info here: http://en.wikipedia.org/wiki/Interlanguage_link http://meta.wikimedia.org/wiki/Help:Interwiki_linking Reproducible: Always
When adding the interwiki links, could we get interwiki links for devmo <-> wiki.m.o, too? That'd be really handsome, esp with at least devmo still being a moving target.
Can we get those wikis to share accounts? That's essential to me, I stopped contributing to mz due to account overflow. (Being able to use an wiki.m.o account on devmo would be vital, too. IMHO.)
MediaWiki has authentication plugin capability, and getting it to authenticate against LDAP would be easy. We just need an LDAP server and a good account management UI for the end users. :) (Bugzilla can use LDAP, too) The LDAP server is bug 34118, and it'll likely be summer before it happens.
Chris, do you have a chapter of your SSO story for us?
(In reply to comment #4) > Chris, do you have a chapter of your SSO story for us? You mean me? Well, I'm still working on this problem, but I just moved in with Andy Smith from SXIP, so expect some movement on this... Do you have any ins that might be useful for making this happen more widely?
I don't mean to be rude to anyone, but this bug isn't about single signon. That's either bug 34118 and it's dependencies or file a new bug.
Also need Polish (pl), German (de). Could I get an ETA on these? There's a team of people who would like to get started on the Polish version, and were asking about it this weekend.
Yes. We're ready to start it asap.
I have the following set up. http://developer-test.mozilla.org/fr/docs/ http://developer-test.mozilla.org/ja/docs/ http://developer-test.mozilla.org/pl/docs/ http://developer-test.mozilla.org/de/docs/ Please test out and give some feedback. The final thing to do is reorganize /en/ in the db, filesystem, and add a few rewrites to move /docs/ to /en/docs and we will be good to go. This will require a minor outage.
Oh, and http://developer-test.mozilla.org/pl/docs/index.php/Test is an example interwiki page.
The french team of xulfr.org is interested to work on the french version of the wiki. We have already translated the XUL tutorial from xulplanet (with the permission of Neil Deakin) : http://xulfr.org/xulplanet/ . Translating the wiki could be the next step for us :-) (I'm the founder of xulfr.org, the first french web site about mozilla technologies)
(In reply to comment #9) > http://developer-test.mozilla.org/fr/docs/ I notice a fault with the french menu topic *Outils personels* : you may write *Outils personnels*
developer-test.mozilla.org/fr/docs/ seems to work fine. Interlang links does work too, just not with en/ of course. Can we go further, begin to organize a team and to translate 'serious' things, or should we wait a little more?
We made a lot of work while waiting for this accounts. Who should I contact in order to push our database from http://splatch.niwidu.org/wiki/index.php/Strona_g%C5%82%C3%B3wna migrated to your db?
(In reply to comment #13) > Can we go further, begin to organize a team and to translate 'serious' things, > or should we wait a little more? Dave and I have been working very diligently to get the new dynamic cluster up and running. Devmowiki is going to be the first service deployed, and we are very close. How about we freeze editing until we have the cluster in production? This should be ready by the end of the week (6/3/05).
> We made a lot of work while waiting for this accounts. Who should I contact in > order to push our database from > http://splatch.niwidu.org/wiki/index.php/Strona_g%C5%82%C3%B3wna migrated to > your db? That would be me. Please provide a gzip'd sql dump via the web or email.
Alex: freezing edits on all the wikis (particularly the english one) is going to be tricky (likely impossible). How important would it be to do a freeze at some point? A shorter freeze (ie: an hour or two) would be much more manageable, if feasible.
(In reply to comment #17) > Alex: freezing edits on all the wikis (particularly the english one) is going to > be tricky (likely impossible). How important would it be to do a freeze at some > point? A shorter freeze (ie: an hour or two) would be much more manageable, if > feasible. Yeah, no problem. I was unaware of how "testing" this wiki was. The only trick will be prepping the sql dumps... which is already mostly scripted. I will finish up my end of the deal and then request we do a freeze to import the dbs (including spanish once I have the dump). This should only require a few hours once the dynamic cluster is in order.
What are we doing with the stuff that is currently on developer.mozilla.org? The data should live on the same servers that have the wiki, so if we want to move it, I need to know. My current todo list is: * finish setting up the clusting software (almost there) * set up another testing environment for the complete production environment (developer-testing2.mozilla.org or something) * Have people test * import fresh sql dumps Then we should be rolling.
I'd imagine for simplicity sake (to avoid having to screw around with the build scripts too much) we should put the wikis in a separate directory tree from the rest of the site content, and use RewriteRules in apache to get /<lang>/docs rewritten into the wiki tree (with the existing devmo content in the actual DocumentRoot).
Deb has put the XTech slides up beneath http://developer-test.mozilla.org/presentations/, without CMS stuff. That calls either for another redirect or for getting the presos into the old CVS, with some nowrap goodness.
Some additional configuration is still needed on the non-English wikis: 1 lower case page titles need to be enabled 2 the Breadcrumb and Titleoverride extensions need to be installed 3 the footer needs the Creative Commons license text stuff enabled 1 and 3 should just be a matter of changing the LocalSettings files.
There has been a new request for a Catalan version of the wiki to be set up for translations (lang code: ca).
There seems to be a problem with the authentification : if I'm logged in in the english wiki and then want to log in the french one, it overrides one of the needed cookies (I think) and I'm not logged anymore on the other wiki. It can be very problematic for instance if someone wants to copy the english content (one has to be logged to see the wiki source) and then paste it in its localized counterpart.
That is a result of no single sign-on, and using many many many different mediawikis installs. The solution I would see for this is to use only one wiki... and have the languages as different categories within the wiki. However, I think we are far beyond that now. Anyone done interwiki authentication and session management?
(In reply to comment #25) > That is a result of no single sign-on, and using many many many different > mediawikis installs. The solution I would see for this is to use only one > wiki... and have the languages as different categories within the wiki. However, > I think we are far beyond that now. There should be a setting somewhere in MediaWiki for a "cookie path". Set that to match $wgScriptPath and it should all settle itself.
/ca/docs/ has been installed... but not set up with 1, 2, and 3 (comment 22).
Catalan version also needs to be added to the interwiki link map.
from #mediawiki: <avar> I haven't done it myself but there has been support for grabbing the user table from another db for some time now, what isn't there is support for migrating accounts <avar> so If you don't mind starting from scratch it's easy sob.
Just a reminder that the items in comment #22 still need to be taken care of. The lowercase page-name stuff is critical at this point, as it is blocking people from getting translation work done properly.
(In reply to comment #30) > Just a reminder that the items in comment #22 still need to be taken care of. > The lowercase page-name stuff is critical at this point, as it is blocking > people from getting translation work done properly. I had a few extra minutes so I gave this a shot... however, I was unable to get even one to upgrade. I am stopped on /ca/ after: # php update-devmo.php PHP Fatal error: Call to a member function on a non-object in /data/devmo-dev/ca/docs/includes/ObjectCache.php on line 409 If anyone has any ideas, let me know. Otherwise I will try and poke at it again soon.
The breadcrumb and titleoverride extensions are those which shaver put together for us. Did you install them using the procedure he outlined in bug 292387? If that's irrelevant, then I'm not sure what the problem would be.
Yeah, thats what I did. Must have messed something up. Just letting you know where I sit and that I am working on it....
Alright, they should all now have the extensions installed aswell as proper interwikis. We are now supporting 6 wikis: ca de en fr ja pl Wiki wiki wiki! Let me know if I missed anything.
(In reply to comment #34) > Let me know if I missed anything. Didn't check myself, are the cookie urls fixed?
(In reply to comment #35) > Didn't check myself, are the cookie urls fixed? I poked around for the config option that Dave mentioned with no luck. From #mediawiki: < polvi> greetings. We have multiple mediawiki installs for different languages. However, when one user logs into a different wiki they get lose the cookie for the previous one... is there anyway to prevent this? < _Hyarion_> polvi: ya if you hack the code :) < polvi> _Hyarion_: there is no LocalSettings.php option or something? < _Hyarion_> no, sorry. < _Hyarion_> that sounds like it would be a fairly common problem though, I'm sure its something they're planning for future releases. Anyone know any different? -Alex
(In reply to comment #36) > (In reply to comment #35) > > Anyone know any different? It depends. What we want to archive? If the goal is to have multiuser wiki. Where all the wikis share the userlist, it seems to be quite simple. We just need to set our cookie for domain (it happens now) and we have to point the same user table in SQL. If we want to preserve logins from different wikis we just need to set cookie not for domain but for developer-test.mozilla.org/lang/docs. Both seems to be quite simple to patch. I can do codign, but someone must decide.
> but someone must decide. I have no preference. Deb?
(In reply to comment #38) > > but someone must decide. > > I have no preference. > > Deb? We really do need the cookies to work. If it's reasonably simple to patch it so that happens, then that's ok. My only concern is ensuring that we don't mess up the upgrade path too much. MW 1.5 seems to be coming along nicely, and we're going to want to upgrade to that as soon as the final comes out. So...we need the cookies to work properly. I'll defer to you guys for sorting out the technical side of things, whatever that entails.
> I'll defer to you guys for sorting out the technical side > of things, whatever that entails. I purpose gandalf do the coding in a style that can be commited to mainline mediawiki. They obviously are interested in the code. Gandalf: Can you file a bug with mediawiki bugzilla and submit the patch you use to solve our problem? http://bugzilla.wikimedia.org/ If you need any of our sources let me know. Otherwise I can upgrade our install with the patch. We are running the latest stable CVS. -Alex
The cookie issue is bug 296085. For the record, I like the single-signon idea. Seems that would be much easier for the translators as they wouldn't have to log in again every time they switched languages. MediaWiki supposedly already supports this.
Ok. So I'm writing a patch that will allow many MediaWikis to use one user table.