There shouldn't be anything wrong with this, because the default language is "en" and without the "?uselang=pt" parameter, the page would be displayed in English, not Portuguese.

volker.haas wrote:

The behavior you describe seems to be perfectly normal. Clicking on any link after manually altering the URL reverts the language back to the original. Therefore I am closing this

Created attachment 8715
Screenshot showing an inconsistent translation of the interface

(In reply to comment #2)

The behavior you describe seems to be perfectly normal.

I disagree on this, since the result is an inconsistent interface, partially translated to the user's language and part in English.

See the attached screenshot.

IIRC it is possible to use ResourceLoader to get the translated messages for use in the [[Special:Book]] page in cases like this (since the page is not reloaded when the user click in those links/buttons).

Attached:

(In reply to comment #3)

IIRC it is possible to use ResourceLoader to get the translated messages for
use in the [[Special:Book]] page in cases like this (since the page is not
reloaded when the user click in those links/buttons).

Krinkle, do you know if that is possible?

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

Seems we switched to talk about JavaScripted interface, so it's a dupe.

• This bug has been marked as a duplicate of bug 17702 ***

Created attachment 16335
Screencast

This has nothing to do with T19702: Missing i18n support for book generation progress messages. See the screencast.

Attached:

This is because it currently still uses deprecated index.php?action=ajax to call wfAjaxCollectionAddChapter() server-side. Which in turn relies on user preferences from the user's session or the wiki's default user language.

In general user language is controlled client-side through wgUserLanguage. Using that will fix these and related issues automatically without any sort of hardcoding for uselang. There is no need to deliver translations via ResourceLoader as the widget in question doesn't use interface messages in JavaScript. Instead, the server returns an already formatted string of HTML. The server-side merely needs to be given the appropiate user language.

Another way to expose a similar bug:

• Open the page plainly (no query parameters).
• Change user language preference in a separate tab.
• Add a chapter.

The added chapter and that portion of the page are now in a language different from the rest.

I initially assumed that this bug would also happen for anyone with a language preference different from the default language (similar to what uselang does), except that more common use case actually works as expected. This is because the deprecated entry point is on index.php, where sessions are always honoured and end up informing the correct language from the session. If this was refactored to an API module, then that could be set explicitly by using uselang=user, or (better) set to the current value of wgUserLanguage.

Back to this bug, it's not easy to fix because all code executed by wfAjaxCollectionAddChapter is static, without context and relies on global state for which language to use. Passing it as a parameter to the ajax function wouldn't work.

Passing it to index.php explicitly could work, however. This would require function req() in Collection.git:/modules/collection.js to be patched.

Re-added tag good first task