Le 22/12/2016 à 19:30, Chad a écrit :
On Thu, Dec 22, 2016 at 10:42 AM mathieu stumpf guntz < psychoslave@culture-libre.org> wrote:
- 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?
Yes, that is a problem. As pointed out by others: it makes grepping for code when doing refactoring basically impossible as I'd have to know a list of every possible translation of "util." That's not a good use of developer time at all.
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.
I mean these ideas have merit on the face of them, but I'm totally in the "this is nice but probably not worth the maintenance burden" camp along with Gergo.
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).
T150417 was declined, and for good reasons I think.
Well, as said, I'm not in fundamental disagreement with that.
I think ideas like Babylscript are more useful for a project where you've got a lot of developers in a *single* non-English language. For example, a team of Italians who would rather work in Italian than English. In our case, we've got *many* languages and being able to use things across wikis/languages is important.
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?
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l