In T122942#3031217, @GWicke wrote:

I updated the description with a recommendation to start by using Accept-Language headers, reflecting the recent discussion.

Per the architecture committee meeting today this RFC is entering its one-week last call period. Please speak up now if you have any concerns or +1s to share. The ArchCom will review the discussion on this task in its meeting on February 23rd, and will either decide based on it, or extend the discussion if more time is needed.

Another solution could be to always disallow editing when a non-default content language was selected. This would improve predictability for clients, but could cost some usability.

it seems from T128239, we are waiting for a document to know the expected way to make the change, any update around the document?

@GWicke , we are using Parsoid API on our prod now, and it's not clear to me what it means by closing this bug, are we seeing any breakage?

@GWicke what about specify language variants via HTTP header? given it is already used for client to specify API version.
advantage:
no need to "abuse" domain or path in a url

I guess @ezachte has answered my question, or maybe there are other options i was not aware of ...

Thanks. Not sure if those dump will be affected by T114019?

Is there any recommended way to get all article's pageviews on a daily/weekly basis?
or I can build my own solution by calling the stats API?

for "Question 2: Which format to return by default", i think it's better to have some announcement before behavior is changed

With T78676 and other related efforts (separating content into different APIs), 50 req/s global limit (limit by UserAgent?) is not enough even for regular incremental crawling,

seems i don't understand why this one (T125033) block T122942, @Shizhao could you explain a little more?

(put offline discussion to keep everyone on the same page)

i was using "extracting displaytitle" an an example for my statement "we constantly have backfill requirements, with more and more development happening around APIs".

could someone explain what's the meaning of "Basically all revision-related information is already available separately as JSON revision metadata."? e.g. pointing me to the (RESTbase) API to get that data?