Recently I'm receiving lot of notifications about suggested pictures for the articles in my watch list.
Hello Seve.
First thank you again for having conducted this session. For those jumping into this discussion, here is some contextualizing resources:
So while ideas I still fresh in our mind, I wanted to dig a bit deeper the point of aliases that was exposed during the session.
To sum up a bit, there are many cases where proper naming has a critical impact on ease of understanding by users. Some example we saw where:
In all these cases, giving the ability to create aliases is a viable solution. My opinion is that is also the case for API. Of course like underlined during the session, it might come with potential downside. Whatever the system, it will have caveats and conveniences. That is, depending on the way things are implemented, the downsides might not have the same extension.
For example, Wikidata take the party to make a numerical identifier be exposed to general contributors, while Mediawiki namespaces can most of the time be used by some localized label. Both come with a different tradeoff.
I am rather confident that we can come with solution that give a tradeoff where most users face only convenient labels, while in the behind the curtails there is a single digital identifier. Think of Bash and Ruby aliases, or even symbols for the later, or enumerations in many programming language. All in all, at the end of the compiler chain, it's all electronic signals.
Here is the dream: a world where you can write a script with any set of identifiers and keywords, and document it in whatever human language you want, and a platform that allows to consult it with any set of matching identifiers and automatically as-good-as-human translated technical documentation in whichever language desired by users. Yes, there is still a long road toward such a world. But aiming at internationalizable/localizable API is an important step toward it.
I think that such a move would conform with our 2030 Wikimedia strategic direction. I invite you to reread its words keeping in mind the critical issue of language diversity, and that according to UNESCO "if nothing is done, half of the over 6,000 plus languages spoken today will disappear by the end of this century".
Can it comes with technical downsides? Yes, possibly, but not necessarily, and definitely there is nothing insurmountable there. Now, let's put that in perspective with the impact we, as a movement, already have on the world, and what efforts are we up to support to take on the challenge of positively influence the preservation of language diversity. Whatever the technical burden, I am confident we will be able to deal with it.
@Psychoslave thank you for your elaborate write up. The platform team recognizes that there is a definite need to provide internationalized/localized API documentation and have considered it as part of our API roadmap.
That being said, there is still work needing to be done around the first modeling what behaviors and capabilities the community needs, how the WMF can better expose and provide those and then we will consider how to ensure the documentation around those API definitions are localized and translated.
Thanks for your feedback Seve. Is there a privileged place where I might follow and possibly contribute toward these efforts?
By the way, are you already aware of Translatable modules?
At this time, not right now but please continue to look for API-related updates soon!
I am not but this is helpful context, thank you
