On Tue, Oct 18, 2011 at 13:31, Oliver Burger <[email protected]> wrote: > Am Dienstag, 18. Oktober 2011, 13:11:33 schrieb Romain d'Alverny: >> On Thu, Oct 13, 2011 at 20:27, Yuri Chornoivan <[email protected]> wrote: >> > http://www.mediawiki.org/wiki/Extension:Translate >> > >> > This extension can significantly ease up maintenance of the translations >> > with no additional efforts to sync translations with original (automatic >> > synchronization). >> >> Actually, we didn't plan to manage l10n that way, but by having >> distinct wiki instances per locale (wiki.mageia.org/en/, >> wiki.mageia.org/fr/ and so on) and interwiki-link them. The same way >> Wikipedia does it actually (and we used to at MDV as well). >> >> So using this extension means a significant change in how we lay things out. > > Since I was away for a few days and had to do some presentation yesterday, I > only now could look into this. > > Please correct me, if I'm wrong! > If I understand this correctly, it wil kind of force syncronization between > the en wiki and the others.
As I understand it, it gives translation progress stats between locales and allows to translate chunks by chunks (so it's a 1-1 translation, with less freedom for a given locale to do things a bit differently - for good and for bad). > As I said in last i18n meeting as well as in doc team, I'd like to keep the > more important things like > - really important documentation > - errata > - information about the project > - ... > in sync. That's clearly a nice feat; does it do it really with this extension? Couldn't this be done as well with a watchdog script on a given set of defined pages, which reports is fed into i18n web page or ml? (or even use mediawiki page watch feature directly). > But I do see fields in which a dezentralization is important as well, > e.g. planning an event can be done very nicely using a wiki (like we did for > FOSDEM 2011 or MandrivaUser.de does for some time. Well, decoupling is not always best, but it helps Here are issues I see with the extensions: - non-localized URLs (instead of w.m.o/en/Home and w.m.o/fr/Accueil (ie, localized title _in_ the URL), we would have w.m.o/Home and w.m.o/Home/fr (English title in the URL); that's not blocking, but that's not so good either; - inconsistent navigation in a chosen locale (tested on the KDE Userbase wiki): - my browser accepts French as a primary language, so content is returned to me in French; - I decide to look at the Spanish version of a page; fine, it works; my intent is to navigate the Spanish-speaking pages now; - clicking on another wiki link will forward me to the default URL, that will be rewritten in French => back to French, where I would have expected Spanish; - right, digging into this, this is because those links are prefixed such as: "Special:myLanguage/Applications" which rewrites to Applications/fr - we didn't plan to setup the wiki that way *, and that's a significant change, so either that is really important for you and it has to be considered _now_, or it can be done differently with the planned wiki setup. * expected wiki setup is: - http://wiki.mageia.org/en/ - http://wiki.mageia.org/fr/ ... and so on, with locale aware interwiki links (the way Wikipedia does it). It certainly has drawbacks too. But the point is that things get done in the end. Romain
