Am Donnerstag, 3. Februar 2005 22:32 schrieb Magnus Manske:
The "big stuff" is surprisingly easy - it's the "little" things that will take time. We have so many functions beyond "edit-parse-render" - the long list of special pages alone. Did you think of how to move and manage the 100+ translations? The interaction with our squid servers? Template dependencies? (I could go on here...)
I did not know all details of the actual wikipedia code. But I have know-how about such projects.
I implement a simple method for translations ( think, you mean more than 100 language translations?), and this method is flexible too. I use a database for all text. All text is read to memory, shared by all threads. On a request there is no need for read the database. If database is changed, a method can be called to refresh the internal buffers while mutex'es avoid conflicts. HTML-Templates can be written like this:
<h2 cpForms:textid="1127" cpForms:textgroup="TIT" cpForms:textnote="Titel Benutzerregistrierung">Benutzerregistrierung</h2>
The Template-Parser delete the extra-tags but look for the textid together with the actual language from Browser / user. The text "Benutzerregistrierung" is used as a default for german in this case.
There were hard discussions about the method of using an identifier for the text (here 'textid=1127'). But it is a effizient method.
A code snippet using translations in C-Code:
PTLangTrans lgTrans; ... /* Language "de", "deu", "de_DE" */ lgTrans = st_cdo->textmap(st_cdo, user->getMainLanguage(user) ); text = lgTrans->findIns(lgTrans, 801, "Admin-Login", "LBL", "Admin-Anmeldung, Administrator oder Forums-Maintainer etc."); composer->assign(composer, "VAL-USRLOGINSUBMIT", text);
With this, the parser get a variable to exchange "{VAL-USRLOGINSUBMIT}" in a HTML-Template. With method findIns() the text will be inserted to the database, if a text is not found.
Manfred