Eventually, Wikibase will need to stop hacking into the Babel extension and (ab)using the {{#babel}} markup as user interface language option. Blocked on T104912 which proposes to consolidate various language preferences options into a single API output.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T122000 Access user language preferences (including Babel) via standard API | |||
| Open | None | T104912 Provide API for (likely) language preference | |||
| Open | None | T122001 Allow manual customisation of user language preferences guess | |||
| Open | None | T148005 BabelUserLanguageLookup is in Wikibase, should be in Babel |
Event Timeline
Comment Actions
Yes why not. There would be many users of this information. But that implications of how to represent these options in the preferences. For example, do we really need the 7-step scale for the fluency? Also migration could be difficult.
Comment Actions
After second thought I think this is wrong. Babel is just one of several aspects of capabilities of users, that is it is an aspect (languages) of a knowledge management system. Other two that should be implemented are skills and location.
We can add this to user preferences, but I'm not sure it really makes sense to add it there. To make use of it it must be published and we must add methods to make other users aware of it. Why should someone be forced to add this if it isn't used? That would imply that the extension could extend the user preferences, but that the user preferences should not be extended by default.
Comment Actions
Hmm, I guess I fixed the Babel part of this bug in rEBAB22b6815c2d33: Add API action=query&meta=babel module. Should it be marked as resolved? I don't really have an opinion on the rest of the API parts, though the dependency order seems a bit backwards to me - we first needed Babel to store it's data in an easily queryable manner (rEBABcd12336cb0a5: Store babel languages in the database) before it can be used in an API...