I sympathize with the goal but accessibility benefits would be far outweighed by maintaince costs. We regularly use grep to find code which is about to be deprecated; wikis copy gadgets from each other; more experienced developers are sometimes asked to help a wiki where the local maintainers have less experience. We have a whole global user group for people who go from wiki to wiki and fix things. And that's not even taking into account the implementation costs, which would probably be massive if it includes stuff like localizing Lua/Javascript language keywords. The Wikimedia community collectively has a lot of experience with web development but not a whole lot of experience with programming language compiler development.

Le 21/12/2016 à 22:42, Gergo Tisza a écrit : Maybe. Or maybe not. I can't judge very objectively without metrics, can I? Well, that's fine, and surely having localized versions of code would fall into your grep process, wouldn't it? Yeah, sure that's a problem, and having a centralized gadget repository is a saner way to go that happen to be number 1 on 2016 Community Wishlist Survey/Results <https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Results> :) Well, I share your concerns, and I don't pretend that I have a perfect out of the box solution which make the best balance between technical maintainability, technical skill dissemination, linguistic diversity/accessibility and so on. Well, that's why the thread is about internationalization, and not localization. Just like they are tools to translate all the Wikimedia non-executable hosted content. Or more generally, the way Wikimedia provide the technical facilities but not the human resources to make it so wide projects constructed on this infrastructure. Once again, I don't have metrics about that (but I admit that to my mind you statements seems relevant).

Hi Antoine, thank you for sharing your feedback and clarifying the whole topic. Le 21/12/2016 à 15:13, Antoine Musso a écrit : 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. 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. :) 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).

Le 22/12/2016 à 19:30, Chad a écrit : Well, then I would say that it's more like a projection of a useful tool for a given situation on an other situation, however similar, where it is no longer that useful. What you want isn't find the lexem (or even any accidentally matching string), but the seme (or semene). In most programming languages there is probably a strong enough correlation between lexem and seme(ne) is strong enough to make a simple regular expression matching useful in many cases. But even their, a grep approach can quickly show its limits (especially with false positive in my experience). Having a tool which let you perform transformations based on an AST is often far more accurate and flexible. Well, I do understand the argumentation, and it does sounds reasonable to me. It's more like I wouldn't place the cursor of maintenance burden tolerance at the same point, especially when I feel it might have large impact on (language) diversity. Also, my understanding is that the main concern here is about letting developers with advanced skills easily go and help in misc. wiki. And as I understand it, this shouldn't be such a big deal with a central repository where most common problematic are (hopefully) already factored in a way which ease maintenance. To my mind, it's compatible with having more local specific problem solved, and possibly some local wrapper of centralized code, in a way which please the local community (which might just as well prefer not to use code localization after all). Well, as said, I'm not in fundamental disagreement with that. To my mind, having a lot of developers with many languages doesn't exclude that we also have developers in a single non-English language as part of the former, does it?