Le 22/12/2016 à 19:30, Chad a écrit :
On Thu, Dec 22, 2016 at 10:42 AM mathieu stumpf guntz <
[email protected]> 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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
