Last modified: 2014-09-06 02:57:50 UTC
At least, given a non-standard name for it. For reference, the project space name contains a non-ASCII character (É) and is set to the project name. Making the same request but changing the page= parameter to start with "Project_talk:" explicitly works; but the 'true' name fails with invalid-page. As far as I can tell, the failure happens within secureAndSplit(), but my understanding of the TitleParser is too limited to divine further.
Extra data point: it would seem that the presence of non-ASCII /anywhere/ in the title makes view-header (at least) fail somewhere in Title::newFromText()
Aha! I was looking in the wrong place - the api call *correctly* returns invalid-page because it's the AJAX /call/ that mangles non-ASCII. In particular, 'É' ends up being encoded as '%25C3%2589' -> the result of uri encoding '%c3%89' -> the proper uri encoded utf8.
Indeed, commending out the call to encodeURIComponent() at modules/new/flow-handlebars.js": 699 Solved the immediate problem: it appears that at least under Chrome, window.location.search is already URI-encoded and the extra encoding then mangles the title for api call.
(Removing the encoreURIComponent() is not a tenable solution is that then breaks different links instead).
Added to trello at https://trello.com/c/C9yEQlnr/
Marc thanks for the report, we should have paid attention to this before enabling Flow on frwiki and hewiki :-) A recent fix to the way Flow encodes params to API calls, https://gerrit.wikimedia.org/r/#/c/158549/ , has fixed this bug as well as a bug in clicking on the watch/subscribe star (https://trello.com/c/v2BorMga).
