Closed Bug 289831 Opened 19 years ago Closed 19 years ago

Need new MediaWikis set up for Devmo translation projects

Categories

(mozilla.org Graveyard :: Server Operations, task, P1)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
Other
Other
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: deb, Assigned: alex)

References

Details

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → major
Priority: -- → P2
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.
Blocks: 292664
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.
Severity: major → critical
Priority: P2 → P1
Assignee: justdave → alex
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.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Ok. So I'm writing a patch that will allow many MediaWikis to use one user table.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.