@Charlie_WMDE can you link your mockup? And clarify what the interaction should look like for you? Then we can fill the BDD part.

@Lydia_Pintscher done. can you take a look? especially the "notes" part

For this, the client-side Bridge code will need to know the string length limits of the repository.

I found the following existing places in the API where Wikibase exposes information about itself:

• action=query&meta=wikibase: client API, exposes URLs (base, article+script path) of “the” connected repository and siteid of this client
• action=query&meta=siteinfo&siprop=general: repo API, contains wikibase-propertytypes (url → string etc.), wikibase-conceptbaseuri (…/entity/), wikibase-geoshapestoragebaseurl (Commons), wikibase-tabulardatastoragebaseurl (same), and wikibase-sparql (WDQS)

Anything else that I missed?

@Addshore For this story (and possibly also upcoming ones) we need access to repo configuration from a client wiki. As researched by @Lucas_Werkmeister_WMDE above, we don't seem to currently have a way to get that information. Therefore, we may need to create a new public API endpoint.

Do you have any requirements or guidance for such a public endpoint, particular with regard to any overarching API strategy?

(Please note that this isn't urgent right now, even though it is probably unavoidable to do it eventually.)

I would just keep it simple for now and mark it as unstable and only for use with the bridge.
Just include what you need there, and call it something like wbbridgesettings for now?
I can defiantly see a need for more things like this in the future but it probably isn't worth the time thinking too deeply about those cases yet.

Is bridge already a part to be deployed for the repo and a part for the client? Or is it currently all the client?

Is bridge already a part to be deployed for the repo and a part for the client? Or is it currently all the client?

We’ve made repo changes motivated by Bridge (T229917: Add tags parameter to Wikibase APIs that edit entities), but I don’t think there’s currently any bridge-specific code in the repo.

I would just keep it simple for now and mark it as unstable and only for use with the bridge.
Just include what you need there, and call it something like wbbridgesettings for now?
I can defiantly see a need for more things like this in the future but it probably isn't worth the time thinking too deeply about those cases yet.

FTR I think this is a working mode which creates an enjoyable illusion of speed in feature teams but buys it with a scattered landscape of half-baked APIs which hurts us in the medium and long term. "thinking too deeply about those cases yet" also implies that we can expect a better moment in time to think about the future than now - which is overly optimistic and, should it ever happen, renders the sum of invest in half-baked solutions misdirected.

This can now be observed on beta.

length restriction looks good from my side \o/

there are some other issues though that i filed separate bug reports for

Given that neither of the newly filed issues originated in this story, would it be fair to call this done?