Hi Antoine, thank you for sharing your feedback and clarifying the whole topic.
Le 21/12/2016 à 15:13, Antoine Musso a écrit :
A few issues:
For both LUA Modules and Javascript gadgets, we would have to make the related MediaWiki components to have their whole API to be translated. So that in a Gadget instead of doing:
Well, API translation is a separated issue from programming language translation. And actually it's a rather far easier topic, especially regarding scripting languages which rely mainly on reference. Anyone can easily propose a Scribunto module which make relexicalised wrapping of "mw", right now, as long as it doesn't use non-ASCII characters. You could actually provide translations right into modules, with something like `mw.lang.fr.chargeur = mw.loader` to build on you bellow example. To my mind, the bigest issue with that can of approach is that the added reference layer can make the script harder to debug.
mw.chargeur.utilisant(['mediawiki.outil', 'mediawiki.annonce']).alors {
fonction () { fonction horloge() { mw.outil.ajoutFSC( '#dateTUC e { 'fontes-taille: 120%; } } } $( horloge() );} )
(Example taken from mediawiki.org Gadget-UTCLiveClock.js)
You can see a few renames, some could be done, others are quite challenging:
- mediawiki.util get renamed to mediawiki.outil
- then changed to alors
- CSS translated to FSC which has absolutely no sense :D
- the HTML element A (anchor) renamed to E (encre)
- A CSS identifier that is changing from #utcdate to #dateTUC
- The invalid CSS 'fontes-taille'
As said the idea is to provide facilities for internationalization, not a localization of everything. Whether some community would like to go into a more or less deep localization process should be up to them. Moreover, to my mind, using the default keywords should always stay possible.
As for each of the above point :
* mediawiki.util get renamed to mediawiki.outil : there is no problem with that, isn't it? * then changed to alors : there is no problem with that, isn't it? * CSS translated to FSC which has absolutely no sense :D : well it is just as meaningful as CSS, whether you know the meaning of the acronym or not, isn't it? * the HTML element A (anchor) renamed to E (encre):
Actually, this is definitely not the way you would localize that. First an anchor is translated as "ancre" in French, "encre" translate "ink". But this really the most little problem with such way to localize. You should assume that your API users a) know how CSS identifier works and so you won't translate such a parameter b) don't know a thing about CSS identifier and provide an API which abstract that for them so that they never provide such a parameter.
* A CSS identifier that is changing from #utcdate to #dateTUC
The same apply here. And while, to my mind, it doesn't make sense to provide that kind of identifier translation facility, you would translate that with #dateUTC (see Temps universel coordonné https://fr.wikipedia.org/wiki/Temps_universel_coordonn%C3%A9).
* The invalid CSS 'fontes-taille'
Indeed, you should rather have something like mon_ancre = méthode_de_récupération_de_mon_ancre(); mon_ancre.taille_fonte_de_caractère("120%");
and your user shouldn't care whether this will produce HTML/CSS, postscript, pdf, or whatever digital layout format out there. :)
etc...
Again I appreciate the idea, but I don't think it is technically doable or worth pursuing. Not to mention that it will be very challenging to debug whenever some code has bug and the issue is referred to more knowledgable developers that happens to not know french or esperanto.
Well, I do agree that it makes debug potentially more difficult, but to my mind the problem is the added layer.
As for the achievability of such a project, it's definitely doable. You already pointed to Babylscript, and I yet have to advance on this project but you can already play with mallupa https://github.com/psychoslave/mallupa and lua-i18n https://github.com/psychoslave/lua-i18n (see the relexicalisation https://github.com/psychoslave/lua-i18n/tree/relexicalisation branch).