Hi. Group 1, development 1.45 ago. From that moment the topline menu moved out of the screen. It was fixed after a little time, but then started another problem that continues now: The addportletlink function adds the custom links not according to the 4th parameter, but all of them at the end of the menu, and notifications dom element does not know about them, so it starts on these custom links, just after user talk, the last regular one. Sorry, can't make a screenshot on this tablet. But the problem was on FF too. Thank you.
@eranroz asked to notify @Volker_E.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Hi @IKhitron, I'm sorry, I don't understand what error you try to describe here? Would you mind adding the error description in your mother tongue and I'll find translators?
Comment Actions
Sorry, @Volker_E, my English is very bad.
I'll try in simple English.
The function addPortLink does not work well. It puts the links on different places than in the past. Users complain they do not used to these positions.
Now in regular English, new details.
It looks like in RTL it adds the new links at the opposite side. Before the new links were added at the left side of the last parameter link, and now at the right side.
For example, before, addPortletLink(..., 'pt-new', ..., '#pt-mywatchlist') was resulted by
... (pt-new) (pt-mywatchlist) ...
and now it's
... (pt-mywatchlist) (pt-new) ...
Thank you.
Comment Actions
That's an unforeseen consequence of fixing T48947. The new link was always supposed to be added before the existing link (that is, on the left in LTR and on the right in RTL), but due to that issue the behavior was broken and the new link was added on the left of the existing link (in both LTR and RTL). Note that the bug only existed in the Vector skin, and this change only affects Vector as well; in MonoBook and other skins, the links were always added before.
The last parameter to addPortletLink() was always documented to act this way (to add the new link before the existing link), e.g. on https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.util-method-addPortletLink and https://www.mediawiki.org/wiki/ResourceLoader/Core_modules#addPortletLink.
I'm afraid you will have to fix the affected scripts/gadgets to match the new behavior :( I'm happy to help if you give me links to the scripts.
As a bright side, this means the behavior is now consistent between LTR and RTL wikis, and between MonoBook and Vector, so after the scripts are updated, their authors will no longer have to handle this differently for different languages and skins.
Comment Actions
This had a bizarre effect on fawiki: the Twinkle portlet menu was shown after (i.e. to the left of) all other portlets, even after the search box. The definition at the time was such that nextNode was #p-views so you would expect that it would be shown before the "Read" tab, and that is how it showed until two days ago. I changed the definition for now such that nextNode is #p-search and it is now shown before (i.e. to the right of) the search box. But it still is confusing to me why having it as the first element will make it go all the way to the left.
Comment Actions
Thank you for your explanation. So, we're stuck with this. :-) It's not a wrong way, of course, it's just we'll need to get used to this. And any fix can't be perfect, because (1) different people have a different set of links, and (2) there is nothing to be clued at the edges.
I'm happy to help if you give me links to the scripts.
Thank you, I'll try to create such a list, but I'm not sure it will be successful.
Comment Actions
Well, it's a very short list. Thanks a lot for your suggestion, but I believe we can do it by ourselves.
Comment Actions
To summarize, this was a change to improve consistency between RTL and LTR behavior, and it will not be changed back.