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).